¿Webs estaticas y desacopladas con Drupal?

 Hola, ¿qué tal? Aquí otra semana más en Drupalizate. Hoy quiero responder una pregunta de hace, pues, ya tiempo, la verdad, de una persona que no sé si me la envió por la web, o no, creo que fue por LinkedIn también. Bueno, la mayoría de gente me contesta por LinkedIn. Bueno, lo que voy. La pregunta del chico era de... generar sitios estáticos en Drupal, con Drupal. Algo de Jamstack usando Drupal. Me gusta la idea de usar Drupal para poder generar sitios estáticos, o parte de ellos, y ser más eficientes, sostenibles. He leído algo de Tom, por ejemplo. Primero de todo, yo no he usado ningún sitio Drupal en estático, 100%, y lo, entre comillas, estático, era porque estaba más cachado, ¿no? Porque Drupal no estuviera en el frontend. Así que mi opinión va a ser bastante sesgada, ¿vale? Primero de todo, para la gente que no sabe de qué estamos hablando, Drupal es una web dinámica, ¿vale? Esto significa que en el frontend... perdón, en el frontend, que el servidor está ejecutando PHP, y al frontend se le pasa el HTML que calcula el backend de PHP. Pero claro, tenemos partes dinámicas porque hay usuarios que vean cosas distintas, dependiendo de cada usuario. Podemos tener, por ejemplo, que el usuario logueado va a ver cosas distintas que el usuario que no está logueado, el usuario anónimo de la web. O al mismo tiempo, podemos tener usuarios anónimos que, por ejemplo, pueden interactuar con la web, pueden tener filtros, por ejemplo, por proximidad, o pueden tener un filtro, una caja de texto, que depende de lo que pongan en la caja de texto, el buscador va a mostrar resultados distintos a otros usuarios anónimos. Eso es dinámico, por final es el servidor hace consultas PHP y MySQL y devuelve cosas distintas a distintos usuarios. Así que Drupal, por definición, es para ser webs dinámicas, no webs estáticas. ¿Qué ventajas tiene una web estática? Pues básicamente seguridad y rendimiento. Una web estática es HTML puro, suponiendo que sea una web 100% estática. Al ser HTML significa que no hay problemas de hackeo, porque si te hackean, pues regeneras toda la HTML y ya está. Y como no hay PHP, no pueden ejecutar nada, ni tampoco hay base de datos en producción. Con lo cual básicamente es webs como las de antaño, es HTML puro y ya está. Y tenemos el rendimiento similar, como es HTML puro y no hay conexión con PHP ni conexión con MySQL, la web va cagando leches. Así que por rendimiento, para webs muy muy grandes que les importe mucho el tema de rendimiento y que la web cague lo más rápido posible, pues supongo que puede tener algo de sentido intentar tener lo máximo ya calculado en HTML. Mi opinión sería de quizá mejorar el tema de las cachés, más que regenerar toda la web entera con formato estático. Como digo, mi opinión es sesgada, pero mi opinión lo digo porque si tienes webs, imaginemos un periódico con muchas URL y que les importa mucho el rendimiento, cada vez que se genera algo, un artículo nuevo, tener que regenerar todas las páginas, o todas o cualquier gente que quiera cambiar un bloque del sidebar, o la página de recomendados de no sé quién, para que no se muestren noticias antiguas en partes de las webs. Es muy costoso regenerar miles o millones de URL de una web. Para mí tiene todo sentido que las webs sean dinámicas y que para cada X peticiones que están fuera de caché se recalculen partes de esa página y que la caché te dure X minutos o horas y que con eso tienes un rendimiento, digamos, el mejor rendimiento posible para esos casos. Pero para esto, que para webs con muchas URL no veo viable el tema de estar generando constantemente o cada pocos días todo lo HTML de todas las webs. Y para webs pequeñas, el rendimiento en Drupal creo que es lo suficientemente bueno como para no tener que preocuparte de generar esto con HTML puro. Por eso digo que yo estoy muy sesgado, yo no encuentro sentido a usar Drupal para generar webs estáticas 100%. En vez de esto, usa ya herramientas ya que están pensadas para ser webs estáticas y los textos que no hagan falta lograr tener un Drupal modificado un nodo y guardarlo, sino directamente que sea un TXT o un feature en background y que esto es lo que se use para mostrar después el HTML, o sea, para compilar el HTML. Que no haga falta tener un MySQL. Creo que se está usando una cosa, en este caso Drupal, para una cosa que no es, en este caso webs estáticas. Así que mi opinión es que yo no la usaría. Pero como digo, puedo estar sesgado porque nunca la he usado y no le veo sentido usarla para esto. Otro tema distinto es el tema de desacoplados como tal. Que quizás se puede interpretar que son semiestáticas. O sea, no es un estático 100% sino que tenemos un Drupal en producción que está 100% online. O sea, una estática la puedes generar en tu local y una vez está generado, tú puedes apagar tu local o nada. El HTML generado es el que está en producción. Pero el Drupal no hace falta que esté 100% encendido. El 100% del tiempo. Con las desacopladas, la idea es que sí, la base de datos y el Drupal, la zona de administración, es siempre accesible para los usuarios que tengan permisos. Para editar, por ejemplo, un periódico, imaginemos que es un periódico, pues el backend, lo que es el Drupal, está siempre activo y habrán editores que crean noticias o editan noticias existentes. Pero el tema es de el frontend, lo que el usuario anónimo ve, es una web, digamos, desacoplada, donde el frontend no es un Drupal sino que es otra cosa. Aquí podría llegar a tener sentido, y aparte se ha puesto muy de moda esto, ahí me sigue costando verlo, porque al final muchas cosas las que te da Drupal por defecto, como son, por ejemplo, la gestión de URL del pasauto, no lo tendías en temas de desacoplados, el tema de las views con búsquedas, tampoco lo tendrías por defecto, la gestión de formularios con webforms, tampoco la tendrías por defecto, y muchas cosas que Drupal y módulos contribuidos te dan, pues no las tendrías, se haría reinventar un poco la rueda con librerías que te permitieran hacer cosas similares. La ventaja podría ser, en teoría, un mayor rendimiento, mayor facilidad de cachar las cosas, y después también el tema de que el equipo de desarrollo de Frontend y el equipo de desarrollo de backend estarían muy separados. Eso significa que en la parte de Frontend se puede encargar una empresa que no tenga ni idea de cómo funciona Drupal, no le haga falta saber ni que es un Drupal por detrás, él solo quiere saber de que la API me escupe estos datos, yo como Frontend cojo estos datos, puntos, acabo. Así que una ventaja puede ser en proyectos muy grandes, con varios equipos, la comunicación entre ellos la puedes, digamos, fragmentar para que no falte que todo el equipo sepa de Drupal. Sobre todo porque hoy en día cuesta encontrar gente que sepa de Drupal. Y esto básicamente en mi opinión también es esgada, en determinados proyectos le puede encontrar sentido a web desacopladas, y yo no he estado en ningún proyecto que sea 100% desacoplado en Drupal, y me cuesta verle también los beneficios, o sea, creo que tiene más contras que beneficios. Sobre todo como decía, esto de las URL, o tema de cachés de Drupal propio y todo esto, cosas que con Drupal las tienes por defecto y te ahorra mucho trabajo, las tendrías que rehacer picando código de Frontend con más mano, digamos. Aún así he visto que por ejemplo con Next.js, a ver si te encuentro la URL, vale, ya he encontrado la URL, es next-drupal.org, es justamente un Next.js preparado para trabajar con Drupal en forma desacoplada. Lo vi hace tiempo y, a ver, tiene buena pinta, pero eso que comentaba antes de hasta cierto punto me chirría en depende de qué casos. No sé si sí que se ha puesto muy de moda el tema desacoplado, pero sí que veo que últimamente mucha gente intenta hacer cosas con ello, pero a menos en mi caso en producción no he visto tantas, la verdad, y que me cuesta verle, sobre todo desde el punto de vista del cliente, esto normalmente es más caro que hacer directamente todo con Drupal. Así que no sé, sinceramente mi punto de vista es muy pesimista con las dos, pero es mi punto de vista, no te puedo aportar mucho más. Así que nada, la semana que viene contesto a otra pregunta que también la encuentro interesante, así que últimamente la gente me va dando bastante feedback.