JAMstack: Las partes de la quimera
E n el reino de la tecnología, JAMstack es una de esas palabras mágicas que deja sorprendido a quien la escucha y con una explicación difícil de dar a quien la pronuncia. Más allá de lo que se diga, JAMstack es una elección fantástica para el front-end en aplicaciones web y que definitivamente vale la pena entender para los desarrolladores front-end.
Sin embargo, definir “JAMstack” es algo complejo. La comunidad lo sabe y por eso hay sitios como jamstack.wtf y jamstack.org dedicados precisamente a explicarnos.
Pero desafortunadamente, hay que tener un entendimiento sólido de tecnologías para desarrollo web antes de que las explicaciones empiecen a hacer sentido. Así que comencemos con lo básico.
(o si quieren, pasen por nuestro nuevo sitio web en www.reign.cl)
Érase una vez…
Cuando empecé a trabajar como desarrollador tenía algo de conocimiento del entorno de front-end en que me estaba aventurando. En ese mundo teníamos JavaScript, HTML y CSS, y luego esto evolucionó en frameworks para Single Page Applications (SPA) como React, Angular y Vue. En aquel entonces existían dos caminos para hacer web apps.
El primer método, -old school- era usar un render del lado del servidor. Para comenzar construías tus páginas en HTML/CSS/JS y luego de eso el server las servía. O podías dejar que el server construyera esas páginas con un lenguaje apto para templates (handlebars, EJS, Jade, etc) en la medida que entraban los requests. Lo malo de tomar esta opción: una posibilidad era que tu contenido fuera estático (muy aburrido) y la otra era dejar que tu servidor hiciera un montón de trabajo. Además de eso, cada vez que un usuario solicitaba una nueva página quedaba viendo una pantalla en blanco, mientras el servidor construía/encontraba las páginas que, luego de eso, se mostraban en el navegador del usuario.
El segundo método era usar un render del lado del cliente: construías una SPA y luego enviabas un montón de carga útil de JavaScript a tu usuario, justo cuando entraba a tu sitio. El usuario quedaba a la espera mientras los JavaScripts se descargaban y luego le tocaba esperar de nuevo, mientras estos JS se renderizaban para la página solicitada. Después del golpe inicial, la app andaba suave como seda, entregando una tremenda experiencia; cada cambio de página que se imprimía con JavaScript estaba corriendo en el navegador del usuario. Pero sucede que la primera carga es la importante. Los usuarios son cada vez más impacientes y una carga inicial muy larga significa, ayer, hoy y siempre, que estás perdiendo tráfico y usuarios.
Esto nos hace pensar en lo difícil de encontrar un lugar o servicio, en el mundo real, que cumpla con las 3B: Bueno, Bonito y Barato. Generalmente solo podemos tener solo 2B.
¿Cabeza de Ratón o Cola de León? El saber popular tiene infinitas comparaciones entre opuestos irreconciliables. Pero lo que es imposible entre animales puede tener salida para nosotros, los humanos.
JAMstack: la otra opción
Hoy es posible dar a luz una criatura que anteriormente era impensable, donde se mezcla y empareja contenido estático y dinámico tanto en el lado del cliente como del servidor.
Hay dos posturas principales a la hora de adoptar esta metodología: la primera es usar Single Page Applications con render desde el servidor y la segunda es usar JAMstack.
SPAs con render desde el servidor:
Con esta opción tienes que mantener tu propio servidor: al comenzar, el servidor hace una renderización previa en HTML/CSS de la página solicitada, para luego enviársela al usuario. Esto significa que los usuarios obtienen este render dinámico relativamente rápido. El servidor también envía un gran balde de JavaScript, que se carga en segundo plano.
Cuando el usuario navega a la siguiente página, la app funciona como una SPA y usa ese JavaScript para imprimir la página nueva, en vez de hacer una solicitud al servidor. La app solo le pide data al servidor (JSON, típicamente) después de la carga inicial de la página.
Algunos ejemplos de esta tecnología son NextJS, NuxtJS y Angular Universal. Por mi parte recomiendo NextJS que hemos usado exitosamente en muchos proyectos, en particular para los trabajos que en Reign estamos haciendo para SMU — -
El problema al tomar esta opción es claro: tienes que mantener tu propio servidor. Esto tiene un alto costo tanto a la hora de pagar (en comparación a tomar el servicio de un tercero), como al momento de asumir las responsabilidades y cuidados que el servidor requiere.
SPAs con pre render:
Si entiendes de lo que hemos hablado, puede que pienses que esta alternativa es algo ridícula. El punto de tener una SPA es tener un render inmediato y dinámico de tu app, en el instante que sea necesario, ¿cierto? Si tienes todo pre renderizado, ¿qué nos queda?
La respuesta es, de hecho, un montón. Cuando construimos una Single Page Application hay muchas rutas o vistas que ya están “cocinadas” y no cambian. Puede que tengas una página para Home, una página para About y además tu contenido principal. Este Home y About realmente no requieren de data dinámica que renderizar, pero con una SPA tradicional todo se imprime dinámicamente y a la vez. Incluso puede que el contenido principal viva en una ruta dentro de algún componente wrapper.
Cuando “construimos” una aplicación con una SPA que usa pre render establecemos qué es lo que puede imprimirse previamente con seguridad y qué es lo que tiene que quedar por renderizarse del lado del cliente, al momento de correr la app.
En vez de tener como punto de entrada una sola página en HTML dentro de la carpeta del build, tendremos múltiples entrypoints. Entonces cuando el usuario pide visitar el About y no el Home, ese HTML del About ya está listo, antes de que entre la solicitud. Después de la carga inicial, el JavaScript se lo toma todo y maneja las transiciones entre páginas, así como las partes dinámicas de la aplicación.
El resultado es una SPA que tiene una carga inicial rápida, en vez de una carga inicial larga y pesada, lo que deriva en una buena experiencia de usuario sin los costos de mantener un servidor.
Algunos ejemplos de esta tecnología son GatsbyJS, Gridsome, NextJS, y NuxtJS; Gatsby y Gridsome están construidos pensando más en la generación estática de sitios, mientras que Next y Nuxt son como una especie de navaja suiza que permite hacer un render desde el servidor y generación de sitios estáticos.
¿Oye y el JAMstack?
Ahora sí podemos hablar de qué es y qué no es JAMstack.
Tal como muestra el esquema de arriba, JAMstack es JavaScript, APIs y Markup. La definición es un poco oscura por sí sola y por eso quise explicar todo lo anterior.
JAMstack, a final de cuentas se trata de hacer sitios increíbles sin correrlos desde tu propio servidor o al menos desacoplando tu front-end “estático” de las fuentes de data en tu back-end. La app en el front-end debe estar compuesta solamente de archivos estáticos y ser su propia base de código. Esto significa que no hay contenido con render desde el servidor.
Puede que esta declaración suene bastante restrictiva pero, en verdad, puedes construir muchísimo contenido dinámico siguiendo estas reglas. En realidad cualquier cosa que puedes construir con una create-react-app o una SPA puede ser un sitio JAMstack. Puedes montar sitios de e-commerce, blogs, páginas para marketing o web apps completas con métodos JAMstack.
Para Saber más
Spread the JAM! Nuestro Frontend Engineer Manuel nos compartió una serie de fuentes para comenzar a entender mejor lo que puede ser JAMstack.
- JAMstack Radio es un podcast muy reconocido en la comunidad. Su primer capítulo fue en 2016, y en tono de una conversación entre amigos, aclaran un montón de temas, discutiendo sobre workflows, editores de rich.text y cosas tan diversas como la industria de productos herbales y el escalamiento de negocios ultra-lean.
- FreecodeCamp tiene un caso interesante de analizar. Todo su website está con una arquitectura completa en JAMStack. Utilizan solo un server como API y todo lo demás es estático. En el artículo que linkeamos explican en detalle cómo implementaron su plataforma e incluso tienen evidencias costo/beneficio.
- Smashing Magazine pasó de Wordpress a JAMStack y tiene un artículo donde cuentan implementaron este cambio para que su sitio aumentará el performance de carga.
- Como equipo de Reign acabamos de construir nuestro nuevo sitio, donde la J es Gatsby, la A es provista por las APIS de Contentful y la M viene por el markup de templates HTML.
- Desde Reign estamos trabajando los discovery sites de Tigo (una telco multinacional). Nuestro J es Angular, A en Contentful y M en HTML. Aquí les presentamos Tigo Bolivia.
Este artículo fue escrito originalmente en el blog de Lee Warrick y lo que lees aquí es nuestra versión chilenizada con extras.
