Seguro que has oído hablar de Gatsby, Hugo, Jekyll, Next,… Toda esta nueva generación de plataformas para la generación de páginas web (ver una lista completa) tienen una cosa en común: la JAMStack.
JAMStack es la nueva tendencia en desarrollo web gracias a sus múltiples beneficios (seguridad, rendimiento, coste,…). El acrónimo JAM viene de sumar JS + APIs + Markup = JAM.
Una arquitectura moderna para el desarrollo web basada en el uso de JS en el cliente, APIs reutilizables y Markup precalculado. – Jamstack.org
A diferencia de otras “stacks” bien conocidas, como la LAMP y la MEAN, la JAM no hace referencia a productos específicos sino a un estilo arquitectónico.
Componentes de la JAMStack
En la JAMStack, el JavaScript se encarga de dar el dinamismo necesario a la página web. Eso sí, el JS se ejecuta 100% en el cliente. No hay ninguna restricción acerca del estilo del código o la librería / framework JS que se puede utilizar. Todos los datos y la lógica de negocio que la web requiera tienen que ser accesibles vía APIs. Un conjunto de plantillas Markdown definen como se van a mostrar estos datos.
Estas plantillas Markdown se renderizan en el momento de desplegar la web, no cada vez que el usuario accede a ella. Esto convierte la web en sí en un recurso estático que se puede servir sin necesidad de tener ningún tipo de servidor web instalado. Por ejemplo, puedes empaquetar la web y servirla a través de una CDN (content delivery network / red de distribución de contenidos ) desde un nodo geográficamente cercano al usuario.
Como véis, la arquitectura JAM es muy diferente de lo que estamos acostumbrados a ver si usamos un CMS tipo WordPress o Drupal puros, donde cada petición individual del cliente implica una consulta a la base de datos del CMS para recuperar los datos a mostrar y renderizarlos con la plantilla correspondiente. En la JAM la web está pregenerada.
Esto tiene muchas ventajas como veremos en seguida pero hay una pregunta obvia: ¿Qué hago cuando los datos que tiene que mostrar mi web cambian ?. Ningún problema, en la JAM la web no es estática sino que es pregenerada. Puedes regenerar la web tantas veces como quieras para que los datos siempre estén actualizados. Una vez regenerada se comporta como una web estática. Simplificando, la web sigue un proceso de Continuous Deployment igual que ya haces (o deberías) con el código. Servicios como Netlify te ayudan a automatizar este proceso. Fijaros que incluso podéis seguir usando WordPress como backend si queréis pero visto como un “headless CMS” al cual accederemos durante el proceso de renderización de la web previa a su despliegue. Los ya mencionados Gatsby y cia pueden configurarse fácilmente para seguir esta aproximación si lo deseas (ej. Gastby for WordPress)
Ventajas de la JAM
Más rapidez
No tienes que esperar a que las páginas se “compilen” cuando intentes acceder a ellas. Vienen ya precalculadas y listas para ser servidas inmediatamente en respuesta a las peticiones de los usuarios.
Más seguridad
Se reducen los puntos de ataque. No hay servidor más seguro que aquel que no existe.
Más barato
Cuando el despliegue de tu web se se limita a un conjunto de ficheros que se pueden servir desde cualquier parte, el sistema es mucho más fácil de escalar y necesita muchos menos recursos computaciones en caso de webs con muchos visitantes. Las CDNs son perfectas (y baratas) para este escenario.
Mejor experiencia de desarrollo
Esta separación y “precompilación-2 en la arquitectura JAM permite un mejor desarrollo y depuración de la web y su integración en procesos de CI/CD clásicos. Además cada vez hay más herramientas y servicios para arquitecturas JAM que hacen cada vez más fácil todo el proceso si sigues estas buenas prácticas.
Imagen de cabecera vía illustrated.dev
Últimos comentarios