El Jamstack no va sobre una tecnología en concreto. Es una arquitectura de desarrollo web donde la importancia radica en el uso de CDN's y servicios desacoplados.
Este artículo está basado en el post Jamstack Explained de Bejamas. Aunque no sea una traducción literal, lo tomo como base por lo genial que me parece su estructura.
Desde hace un tiempo sigo de cerca los artículos publicados por Bejamas, una empresa que desarrolla proyectos Jamstack. Me encanta la forma de escribir sus posts, explicando conceptos relativamente complicados de un modo que resulta fácil seguir y entender.
Introducción
El Jamstack ya no es algo marginal. Su creciente adopción durante el año 2020 lo ha demostrado. Ha crecido para convertirse en un ecosistema de herramientas que ayuda a los desarrolladores a construir sitios web, aplicaciones web progresivas y otros proyectos con un rendimiento y unos beneficios que son imposibles de ignorar.
Además de Netlify, creadores de este concepto, ya tenemos a grandes proveedores que ofrecen servicios para desarrollar con esta arquitectura, como AWS Amplify, Azure Static Web Apps o Cloudflare pages. Finalmente el Jamstack está haciéndose un sitio, es indudable cuando grandes marcas como PayPal, Nike, Braun, Shopify o FreeCodeCamp han adoptado esta filosofía.
Qué es el Jamstack
En su momento, Mathias Billman (CEO de Netlify) propuso el término JAMstack como abreviatura de JavaScript, API's y Markup. El significado que tiene hoy en día ya no es el mismo, es mucho más. Puedes ver una evolución del significado del término en este artículo.
El Jamstack ha pasado a referirse a una arquitectura de desarrollo web que permite a los desarrolladores aprovecharse de las ventajas de los sitios estáticos (mejor rendimiento, más seguridad...) al mismo tiempo que siguen pudiendo crear webs y aplicaciones con el dinamismo que permiten las bases de datos de los CMS, eso sí, sin la base de datos.
Esta forma de desarrollar hace posible crear sitios totalmente dinámicos, sirviendo todos los recursos necesarios de forma pre-renderizada a través de una CDN. El dinamismo que hasta hace unos años era una responsabilidad clara del backend, ahora se gestiona con JavaScript en el lado del cliente, normalmente a través de funciones serverless.
Para entender la diferencia, podemos comparar esta aproximación con el clásico stack LAMP.
Proceso de desarrollo estático vs Proceso de desarrollo dinámico
El origen de la arquitectura LAMP está en cuatro componentes opensource que, al rededor del año 2000, los desarrolladores adoptaron para construir sitios web: sistema operativo Linux, el servidor HTTP Apache, base de datos MySQL y lenguaje de programación PHP.
Con los sitios web construidos con el stack LAMP, como por ejemplo cualquier web hecha con Wordpress, por cada petición de una página que hace el usuario, el servidor primero consulta la base de datos y combina el resultado con el markup y los plugins para generar un documento HTML para el navegador.
Por otro lado, los sitios web creados siguiendo la arquitectura Jamstack sirven páginas que han sido pre-renderizadas y todos los recursos ya optimizados de forma más rápida. Eso es posible porque no es necesario hacer ninguna consulta a la base de datos al estar todos los archivos ya renderizados y preparados para ser servidos al navegador desde una CDN.
Resumiendo, el flujo de trabajo aplicado con el Jamstack reduce enormemente incómodos obstáculos del desarrollo y el posterior exceso de mantenimiento necesario.
¿Entonces el Jamstack son páginas estáticas?
Sí y no. El producto final que se obtiene con los sitios web Jamstack son archivos estáticos, pero no están exentos de cualquier funcionalidad dinámica que puedas imaginar, como formularios, comentarios, pasarelas de pago y demás. Normalmente este dinamismo se gestiona a través de API's de terceros.
En el caso del Jamstack, la palabra "estático" no significa "fijo", sino libre de servidor. El navegador no va a necesitar interactuar con ningún servidor para mostrar las partes dinámicas de la web. Esta aproximación viene con muchos beneficios y algún que otro inconveniente.
Historia del Jamstack
Seguramente te has fijado que más arriba has visto en una ocasión "JAMstack" en vez de "Jamstack". JAMstack es el término que se acuñó en 2016 por los desarrolladores que querían darle un nombre a su diferente metodología de desarrollar sitios web estáticos. Esta metodología incluía el backend desacoplado del frontend, diferenciación entre las etapas de construcción y alojamiento, además de las ventajas ofrecidas por las CDN.
En sus inicios, J, A y M en JAMstack eran por JavaScript, API's y Markup. JavaScript en el lado del cliente aporta la programación dinámica durante los ciclos de peticiones y respuestas. Las API's reutilizables y accedidas por HTTPS con JavaScript abstraen todos los procesos del lado de servidor o acceso a base de datos. Las plantillas de Markup deberían de ser preconstruidas durante el despliegue, utilizando un generador de sitios estáticos o una herramienta de construcción de aplicaciones web.
El término evolucionó y dio lugar a una adopción más amplia de la idea y las mejores prácticas detrás de ella, no solo para el J A M.
Las mejores prácticas del Jamstack
Actualmente para obtener los beneficios de la arquitectura Jamstack hay que seguir las mejores prácticas que se aconsejan:
-
Servir el proyecto desde una CDN
-
Todo el código está en un repositorio Git
-
Automatizar las builds o generación de páginas y hacer despliegues atómicos
-
Invalidación instantánea de caché
-
Uso de herramientas de construcción modernas para ayudarte en los puntos anteriores
Adopción del Jamstack
Gracias a los beneficios que trae por defecto la arquitectura Jamstack, los flujos de trabajo incomparables, las herramientas existentes, el Jamstack ha experimentado un incremento enorme en popularidad y uso en los últimos años.
Puedes consultar su evolución en el Web Almanac 2020.
El ecosistema Jamstack
Hay algunas cosas que han influenciado en aumentar la adopción del Jamstack. El incremento de las funcionalidades de los buscadores, el crecimiento de servicios con API o enfocados a API, los Generadores de Sitios Estáticos, el cada vez mayor número de Headless CMS y el más que extendido uso de CDN's para una mejor distribución del contenido.
Actualmente existen más de 300 Generadores de Sitios Estáticos diferentes, cada día aparecen más servicios que incluyen API de integración para tu proyecto, como búsqueda en el sitio web, gestión de formularios, vídeos, etc.
Por qué deberías estar usando Jamstack
Cuando hay que desarrollar una web o aplicación, siempre se intenta tomar la mejor decisión para cada caso de uso. Eso sí, teniendo siempre presente posibles ahorros en los costes. Cuando se explica en qué consiste el Jamstack, todo parece increíble y demasiado bueno para ser cierto. Es importante conocer el detalle de sus beneficios en comparación con el desarrollo tradicional de páginas web.
Rendimiento
Las cargas de página son más rápidas que con el enfoque tradicional con servidor, al estar ya pre-renderizadas de forma estática en la CDN. Además, otro beneficio de servir archivos estáticos es que nos podemos despreocupar de que un pico de tráfico vaya a afectar al rendimiento ni a provocar caídas.
El rendimiento del sitio web tiene una influencia directa en la experiencia de usuario por tanto también en el tráfico que se recibe y en el SEO. Lo sitios web optimizados en cuanto al rendimiento tienen ventaja sobre los sitios web más lentos.
Seguridad
No hay bases de datos o servidores de los que preocuparnos. Aunque en realidad sí que hay servidores y bases de datos, no es algo de lo que nosotros nos tengamos que preocupar. Otros lo hacen por nosotros. Con Jamstack, el frontend y el backend están desacoplados y se ejecutan procesos en los servidores a través de las API's.
El Jamstack trae por defecto unos beneficios que a otras aproximaciones muchas veces les falta. La separación clara de los servicios hace que sea mucho más difícil encontrar vulnerabilidades. Imaginemos que tenemos un blog que usa un Headless CMS. La web que se sirve es simplemente un puñado de HTML, JavaScript y CSS. Difícilmente va a haber una vulnerabilidad ahí.
Escalabilidad y alojamiento
Escalar los recursos puede llegar a ser complicado, pero... ¿recuerdas cómo se sirven los archivos cuando usas Jamstack? ¡Correcto! Desde una CDN. Tu no tienes que escalar nada, otros lo harán por ti. Ya puedes tener 10 visitas como 50.000, que tu web va funcionar igual de bien en ambos casos.
Por otro lado, nos ahorraremos los costes del alojamiento web tradicional. Aunque también pueda haber costes por este concepto, siempre va a ser mucho más barato.
Mantenimiento
El Jamstack implica poner la web directamente en el lado del usuario. Nos ahorraremos los costes derivados de mantener directamente la infraestructura. Al no tener que lidiar ni con bases de datos, ni actualización de plugins o mantenimiento de servidores, podremos ahorrar en costes tanto operacionales como de desarrollo.
Experiencia para los desarrolladores
Desde el punto de vista del desarrollador, todo es muy bonito. Plataformas como Netlify, Vercel, AWS Amplify y otras han facilitado muchísimo el flujo entre el repositorio de Git, la configuración de la integración/distribución continuada y actualización de la CDN.
Nosotros solo nos tenemos que preocupar de desarrollar y hacer un push. Lo demás ocurre automágicamente: vista previa de la aplicación, facilidad para deshacer cambios, posibilidad de ejecutar funciones cloud en entorno de desarrollo local, control de redirecciones, cabeceras HTTP... y más.
Lo anterior, sumado a la flexibilidad de no tener que estar atando cabos entre frontend y backend y el uso de API's de terceros para añadir más funcionalidad hacen que nos podamos focalizar mucho más en el desarrollo de la aplicación, permitiéndonos trabajar primero en la lógica de negocio del proyecto antes que en encontrar soluciones a las limitaciones que pueda tener el backend.
Limitaciones del Jamstack
El Jamstack es revolucionario desde varios puntos de vista. Puede ayudarte a crear mejores webs y aplicaciones, a presentar tu negocio de mejor forma que la competencia. No obstante, como todo en este mundo, también trae limitaciones e inconvenientes.
El Jamstack no es para novatos
Ahora mismo este enfoque está orientado a ayudar a los desarrolladores que ya tienen experiencia con frameworks como Vue, React, Svelte o similares. Lo bueno es que es posible crear productos que sean usados posteriormente por usuarios finales gracias a las herramientas que ya existen.
El uso de datos en tiempo real o específicos del usuario
Algunas cosas no se van a poder pre-generar, como los datos concretos de los usuarios o datos en tiempo real como un avatar, el nombre o información del usuario logueado. Apostar o no por una arquitectura Jamstack en estas situaciones dependerá de cada caso de uso.
Por ejemplo, un clon de Twitter o un panel analítico, seguramente sean buenos ejemplos donde, aunque sea posible hacerlo, quizás usar Jamstack no sea la mejor opción, no se necesitan los beneficios que aporta. Pero para proyectos como un ecommerce, recoger la información necesaria de una API no es complicado.
Complejidad de las API's
Puede llegar a ser abrumador tener que escoger la solución perfecta entre tantas donde elegir, pero lo mismo se puede argumentar con Wordpress y su ecosistema de plugins, por ejemplo. Vale la pena remarcar por eso, que la diferencia en este ejemplo es que, siempre que se recojan los datos de la API en el momento de construir el sitio (al ejecutar el típico comando build), tu sitio en producción no va a tener fallos. Un plugin sí puede romper un sitio web en un momento dado.
Tiempo necesario para el proceso de construcción
Cuando se ejecuta el comando para construir el sitio, todas las páginas van a ser creadas. En este proceso se hacen todas las llamadas a las API's para pintar en cada página la información que necesita. Si tu web tiene un número elevado de páginas, este proceso se puede demorar un buen rato. Imagina un blog con 10.000 artículos. Además, cada vez que se haga un cambio, aunque sea pequeño, todo el sitio va a tener que ser reconstruido. Esto puede llegar a ser un problema.
Ya han ido apareciendo soluciones a este inconveniente, y no son otras que las construcciones incrementales, que permiten recrear solo las páginas relevantes, las que han sufrido cambios, dejando intactas las demás.
Gestionar las partes dinámicas de la web
Utilizar Jamstack no significa que no vayas a usar un backend. Todo lo contrario. Una parte importante de esta arquitectura la forman funciones serverless, que con el paso del tiempo han ido mejorando y ya es posible ejecutarlas en el extremo del cliente, igual que los ficheros estáticos que son servidos desde una CDN.
Las partes de backend que forman tu aplicación o web pueden escalar de forma casi infinita sin requerir ningún tipo de mantenimiento. Además, los usuarios podrán obtener información del backend desde el centro de datos más cercano.
¿Cuándo usar Jamstack?
Evidentemente hay que analizar pros y contras respecto a los objetivos que tengamos y el presupuesto disponible. A parte de eso, hay varios puntos importantes a tener en cuenta.
Si el rendimiento de la página no necesita ser optimizado al máximo y no es del todo necesario usar cacheado de páginas, entonces no hace falta que uses Jamstack.
Si el equipo está acostumbrado a Wordpress y no quieres invertir tiempo y/o dinero en formación para aprender y adoptar una nueva tecnología, no apuestes por el Jamstack.
Si tu proyecto depende básicamente de datos en tiempo real o datos de usuario, el Jamstack no te va a aportar casi nada nuevo.
Finalmente, puede que no siempre tenga sentido migrar proyectos antiguos al Jamstack, pero si empiezas uno nuevo, esta aproximación es algo a tener en cuenta.
Por otro lado, si lo que buscas es incrementar el rendimiento de tu página o aplicación web, hacerla más rápida para el usuario y al mismo tiempo que sea más seguro mientras mantienes a los desarrolladores enfocados en lo más importante, desde luego el Jamstack es el camino ideal.
Primeros pasos con el Jamstack
Ya hemos visto un poco los orígenes del Jamstack, los beneficios que aporta y sus limitaciones. Aunque se haya mencionado alguna de las herramientas que se usan para usar esta arquitectura, todavía no hemos comentado el detalle de las mismas.
Antes de empezar, hay que tener claro que el Jamstack está enfocado al desarrollo de frontend, por lo es muy recomendable que el equipo de desarrollo ya tenga experiencia previa con JavaScript y uso de API's.
Para crear la web o aplicación, lo más habitual será usar un framework JavaScript, como puede ser Vue, React, Angular o Svelte, hay muchos, incluso puedes optar por usar Vanilla JavaScript. Además, será necesario usar también un Generador de Sitios Estáticos. Otras herramientas que usaremos serán un Headless CMS y una plataforma de alojamiento y despliegue compatible con Jamstack.
Generador de Sitios Estáticos
Son una herramienta que construyen páginas HTML estáticas a partir de ciertos archivos de entrada. Tanto si coges el contenido desde un CMS o desde donde sea, el SSG (Static Site Generator, por sus siglas en inglés) aplica una plantilla que tendremos preparada y generará una estructura de archivos HTML puramente estáticos, todo listo para ser publicado en la web.
Hay muchos SSG disponibles, en este blog hemos hablado de Eleventy, pero puedes ver una inmensa lista en la guía de SSG de Bejamas.
Headless CMS o CMS sin cabeza
Probablemente ya hayas visto muchas veces el término CMS, por las siglas en inglés de Content Management System. Wordpress, Drupal o Joomla son ejemplos de CMS tradicionales, aunque no son exactamente igual que los que veremos a continuación.
El CMS tradicional necesita un servidor donde estar alojado y se sirve una página por cada petición que hace el usuario. Toda su arquitectura se basa en un frontend y un backend acoplados, lo que se suele llamar un monolito. Por el contrario, un Headless CMS desacopla la gestión del contenido del sitio web final. Son una herramienta que permiten crear contenido de forma fácil al igual que lo hace un CMS tradicional, pero para obtener ese contenido ponen a disposición una API. Eso permite hacer entrega de contenido de una forma centralizada, desde un mismo sitio, hacia uno o más frontends.
Lo más probable es que la gran mayoría de Headless CMS disponibles se adapten a la tecnología de frontend que estés usando. Puedes ver un listado de Headless CMS muy completo en la página oficial de Jamstack.
API's
Como ya has visto, las partes dinámicas de la web se van a gestionar mediante API's, aunque también tienes la posibilidad de desarrollar tus propias soluciones. Lo que pasa es que probablemente no se tenga el tiempo y el dinero necesario para desarrollar funcionalidades que otros ya tienen muy bien hechas a disposición de los demás.
Hoy en día hay soluciones con API para prácticamente todo, desde el procesamiento de pagos online (como Stripe o Paypal) hasta la gestión de la autenticación de usuarios (AWS cognito, Auth0), pasando por el manejo de formularios web (Netlify Forms, Kwes). Es lo que se llaman microservicios, aplicaciones que aportan una funcionalidad muy concreta. Hay una empresa detrás de cada una que se dedica exclusivamente a que esa funcionalidad sea lo más perfecta posible.
Plataforma de despliegue
Una vez ya tienes listo tu sitio web o aplicación Jamstack, hay que encontrarle casa. Actualmente las plataformas de alojamiento y CDN han evolucionado mucho, ofreciendo la funcionalidad necesaria para gestionar sitios web modernos.
Netlify y Vercel son las soluciones pioneras, pero también hay que tener en cuenta que gigantes como AWS, Google Cloud o Microsoft Azure también ofrecen este tipo de plataformas.
Cómo va a seguir evolucionando el Jamstack
No es la solución perfecta para cada caso de uso. Eso sí, el ecosistema está creciendo y adaptándose rápidamente, de forma continua. La enorme cantidad de herramientas disponibles que están enfocadas a esta arquitectura son una buena prueba de ello.
Frecuentemente aparecen nuevas herramientas que ofrecen nuevas funcionalidades y expanden los límites de lo que es posible hacer con un sitio estáticamente generado.
Ya se ha superado la transición desde el backend hasta un mejor y más poderoso frontend, mucho más efectivo. Solo hay que seguir la carretera que tenemos delante, una carretera donde en el horizonte se ve un Internet mejor para todos.