Jamstack / JAMstack
Ricardo Vega / 12 noviembre 2020
⏰ 13 minutos
Ricardo Vega / 12 noviembre 2020
⏰ 13 minutos
Este es uno de esos posts que llevo tiempo intentando encontrar el momento adecuado en el que sentarme a escribir sobre él. Hace unos meses, te contaba como llevaba un tiempo trabajando en la re-escritura del motor que da vida a este blog y cómo para ello había elegido Gatsby por estar basado en react, tecnología con la que trabajo diariamente y que conozco bien.
Lo que no te conté por aquel entonces, es que Gatsby es una herramienta que se encuentra englobada dentro de un patrón aún mayor llamado JAMstack o (recientemente renombrado) Jamstack. Por fin he conseguido encontrar ese tiempo para poder hablarte de él.
No me quiero poner excesivamente técnico, pero sí me gustaría dotar del contexto que considero necesario para entender por qué surge JAMstack (de momento emplearé este término) por lo que empecemos por el principio.
Para contestar esta pregunta debemos entender que habitualmente, en esta tarea van a estar involucrados tres actores:
Es importante que tengas en cuenta que este simple esquema puede variar mucho en aplicaciones modernas donde paradigmas como los microservicios o el cloud nos pueden dar lugar a infraestructuras distintas pero creo que, incluso para estos casos, podemos emplear esta simplificación para entender desde el punto de vista del navegador como se pinta o más técnicamente "renderiza" una aplicación web.
También debemos tener una noción básica sobre qué es "renderizar". Tu navegador web entiende tecnologías concretas y en el caso de qué ves (el contenido) lo haces a través de HTML que es un lenguaje que, mediante etiquetas, describe la estructura de una web y su contenido. El navegador interpreta ese HTML y lo pinta gráficamente apoyándose en estilos definidos a través de CSS (aunque esto último es irrelevante para la explicación que queremos ver hoy).
Con esto claro y atendiendo a estas tres cajas podemos diferenciar distintos escenarios:
Renderizado en el lado del servidor, concretamente, en el servidor de la aplicación. Puedes ver en el siguiente esquema como se comportaría una aplicación que emplee esta tecnología:
Como ves, el navegador pide contenido al servidor web, que simplemente hace de pasarela y envía dicha petición al servidor de aplicaciones quien tras recibirla, procesa la petición, llevando a cabo las tareas que tenga que realizar (consultar base de datos, otros servicios, cálculos) y es él mismo quien genera el HTML que es enviado de vuelta al navegador a través del servidor web. Al llegar al navegador, éste simplemente debe renderizarlo.
Este patrón, perfectamente podría haberse llamado Client Side Rendering o renderizado en el lado del cliente ya que el proceso de creación de HTML se lleva a cabo en el cliente, en el navegador. SPA viene a hacer referencia a su comportamiento, ya que normalmente en estas aplicaciones las navegaciones entre páginas no son tal, sino que lo que van es recargando su contenido lo que hace que sean mucho más dinámicas y mejoren la experiencia de usuario
Esto ha dado lugar a un auténtico "boom" y actualmente (2020) es un patrón muy presente en el desarrollo web, diría que claramente mayoritario.
Como puedes ver en el siguiente esquema, en este caso, la petición iniciada por el navegador llega al servidor de aplicaciones de igual modo que lo hacía en SSR, quien igualmente llevará a cabo todas aquellas tareas que podemos englobar dentro de "procesar la petición", pero en este caso, una vez obtenida la información que debe devolver al cliente, no genera HTML, sino que emplea un formato de transmisión de información con es JSON. Es decir, al navegador le llega información en bruto y es este quien, a través de JavaScript, convierte esta información en HTML que el navegador pueda interpretar y renderizar. Al hilo de este proceso, es donde han crecido frameworks como React, Vue, Angular y otros muchos que precisamente se especializan en llevar a cabo esta tarea.
Sin embargo, existe una tercera vía: en las dos anteriores formas hablábamos de cómo el servidor procesa la petición, bien sea para generar HTML directamente o un JSON con información en crudo, pero esto puede que haya veces que no sea necesario. Si nuestro contenido es estático, es decir, que no cambia según quien nos consulte o cuando lo haga, podríamos generar previamente todo el contenido de nuestra aplicación, crear nuestros HTMLs y tenerlos listos para devolvérselos al navegador cuando este nos los solicite.
Pero es que estos HTMLs, al no necesitar procesado, podemos alojarlos de forma directa en el servidor web y prescindir del servidor de aplicaciones puesto que no necesitamos ningún "cerebro" que genere contenido al estar este ya previamente generado.
Puedes ver el esquema a continuación:
Como ves, el servidor web almacena todas las páginas HTML que conforman el sitio y simplemente se lo devuelve al navegador cuando este solicita una nueva web. Es una arquitectura muy sencilla que además se beneficia en un notable ahorro operativo ya que el elemento más caro de todos los hasta ahora presentados es sin duda el servidor de aplicaciones.
Evidentemente, no es oro todo lo que reluce y este patrón sólo podemos aplicarlo a sitios donde el contenido sea estático. Voy a intentar explicarlo con un ejemplo que seguramente todos tengamos en la cabeza: Netflix:
Cuando accedes a la web de Netflix con tu cuenta de usuario, ésta te muestra contenido personalizado a tus gustos, a tu región geográfica e incluye información sobre últimos visionados para que puedas continuar de forma sencilla tu serie favorita desde donde la dejaste. El contenido decimos que es dinámico ya que "depende" de un montón de variables. Esta clase de contenido no podemos pre-generarlo de antemano por lo que Netflix no podría ser un sitio web estático.
Sin embargo, porfolios y blogs (como este) si que conocemos su contenido de antemano y no varía si lo ves tú o una persona que llega a través de Google al otro lado del globo. Es estático y por tanto sí podemos emplear esta arquitectura (y de hecho, lo hago).
SEO es el acrónimo se Search Engine Optimization y es la especialidad que se preocupa porque las web se visualicen correctamente en Google, Bing, etc y que ocupen la posición más alta posible, lo que muchas veces está directamente relacionado con cómo el crawler (el bot que rebusca por todo internet las webs publicadas para añadirlas al directorio del navegador en cuestión) visualiza la aplicación / página.
Pues bien, hasta no hace mucho, estos crawlers no entendía Javascript lo que a efectos prácticos hacía que las SPA de cara al navegador fuesen una página en blanco. A día de hoy, la compatibilidad con Javascript ha mejorado, pero aún sigue siendo errática por lo que existe un consenso generalizado de no usar SPAs cuando el SEO importa dentro de una aplicación y optar por SSR o sitios web estáticos al mandar estos patrones al navegador (y al crawler) directamente HTML que sí puede ser interpretado.
El término JAMstack nace en 2016 en la SmashingConf San Francisco donde el CEO de Netlify presenta una charla titulada The New Front-end Stack. Javascript, APIs and Markup. Es más, JAMstack es un acrónimo de JavaScript, APIs, y Markup stack.
La idea es construir aplicaciones web a través de Javascript, generando el contenido estático previamente y dinamizando aquellas partes que necesiten a través de APIs específicas y especializadas, a menudo consumidas como servicio y por tanto fuera del foco central de la aplicación. Por ejemplo, autenticación, búsqueda, APIs geográficas o de pago podrían ser buenos ejemplos de APIs que podemos consumir de un tercero sin necesidad de tener un conocimiento muy profundo de ellas dentro del equipo de ingeniería de la aplicación.
Por esta época, el uso de lenguajes de marcado como Markdown, reStructuredText (RST) o AsciiDoc ya estaba bastante popularizado entre la comunidad de desarrolladores (y no desarrolladores). Actualmente, es muy habitual y a nadie nos sorprende entrar en un proyecto open source alojado en Github o Gitlab y encontrarnos un README.md escrito en Markdown. Esta tendencia, se introduce dentro del núcleo de JAMstack a través de esa "M" que hace referencia a Markup.
Las ideas centrales que se persiguen son:
Podríamos decir que JAMstack, es una idea heredada de la arquitectura que hemos titulado "Static Sites" en tanto en cuanto se apoya en la pre-generación de todo aquel contenido que sepamos de antemano pero que lo amplía con el uso de APIs para poder incluir también contenido dinámico.
jamstack.org es el centro de esta arquitectura y es quien, aunque inicialmente empleaban el término JAMstack, lo ha simplificado a Jamstack. Aunque puedes ver los motivos en este artículo, podríamos resumirlo como que se quiere englobar dentro del término las ideas principales que persigue y la forma de construir aplicaciones aplicando esta "filosofía" y no tanto hacer hincapié en las tecnologías que formaban el acrónimo.
Como principales beneficios de su uso nos encontramos con:
Puede que si has llegado hasta aquí, te estés preguntando si realmente existen diferencias entre sitios estáticos y Jamstack ya que sus características parecen muy semejantes. En realidad, creo que es una pregunta muy conveniente porque en efecto, sus diferencias son muy vagas. En mi opinión, todo lo que propone Jamstack se podía hacer ya con un generador estático. Es más, este blog inicialmente nació en Wordpress siguiendo una estrategia SSR y posteriormente lo migré a Pelican que es un generador de sitios webs estáticos. Pero no todo su contenido era estático, por ejemplo existía un formulario de contacto o una caja de comentarios que eran dinámicos y estoy hablando de septiembre de 2016 cuando yo no había ni siquiera oído el término JAMstack que había sido "creado" en abril de ese mismo año. Es más, muchos blogs ya estaban usando tecnologías y arquitectura similares a la mía mucho antes de 2016.
Creo que Jamstack formaliza no tanto una arquitectura o tecnología sino una nueva forma de construir aplicaciones con repercusiones no sólo técnicas sino también económicas (economía de APIs). Da un nombre nuevo e inicia una moda sobre los cimientos de los sitios estáticos. No es casualidad que todos los generadores de sitios web estáticos estén ahora incluidos en esta lista de generadores de Jamstack.
Supongo que Jamstack lo podemos considerar un marco de trabajo en el que empleamos generadores de sitios web estáticos para generar toda la parte estática y después lo vitaminamos con Javascript para aquellas partes dinámicas que lo necesiten. Si sólo estamos ante contenido estático, tal vez lo más apropiado sería emplear "web estática" pero creo que por norma general no es erróneo usar Jamstack o sitios webs estáticos de forma indistinta.
Por tanto, creo que en cierto modo, comparten ventajas y desventajas y por tanto hay casos de uso claro para Jamstack como blogs o porfolios pero a medida que se incrementa el dinamismo del contenido de la web, dicho patrón tiene menos sentido. Sin embargo existen casos de éxito dentro de e-commerce cuyo contenido es estático (los productos son los que son) pero a la vez hay bastante información dinámica (usuario autenticado, preferencias de dicho usuario, stock, pago, etc) por lo que creo que Jamstack puede ser capaz de cubrir un abanico amplio de opciones, expandiendo los horizontes de los sitios web estáticos "tradicionales" por lo que, al menos en mi opinión, es una opción al menos a considerar en gran número de aplicaciones.
Es verdad que Jamstack es un término muy ligado a Javascript ya que, en mayor o medida, es necesario emplearlo para la parte dinámica pero creo que existe una corriente importante para que los generadores como tal del contenido estático puedan emplear cualquier tecnología como Python (Pelican), Go (Hugo) o Ruby (Jekyll). Todos ellos son nombres importantes y reconocimos dentro del panorama Jamstack pero tal vez la herramienta que más lo ha popularizado es Gatsby, framework javascript y que será el protagonista principal de mi próximo post.
Hasta entonces,
Ricardo