Qué es JAMstack, qué es Gatsby y cuándo usarlo

En este artículo hablaremos del paradigma Jamstack, soluciones que lo desarrollan como Gatsby y sobre cuándo es conveniente utilizarlo.

Qué es un stack

Cuando hablamos de un stack de desarrollo nos referimos al conjunto de herramientas y tecnologías que componente el ecosistema de desarrollo. Normalmente, también lo llamaremos pila de desarrollo por su traducción al castellano. Por tanto Jamstack es un stack, una pila, de herramientas específica para el desarrollo de paginas y aplicaciones web. Jamstack es uno más de los muchos stack o conjunto de herramientas de desarrollo de aplicaciones web que existen.

En qué se diferencia JAMstack del resto de stacks

Seguro que te suena MEANstack. Es el stack compuesto MongoDB, ExpressJS, AngularJS, NodeJS, para crear aplicaciones web de una sola página, también llamadas Single Page Aplications o simplemente SPA. Este stack utiliza MongoDB para la persistencia de datos, Expresjs para la API de comunicaciones entre la capa front y la capa de persistencia, Angularjs para crear la capa front y NodeJS para ejecutar las herramientas de desarrollo y distribución propias de este stack.

JAMstack es el stack compuesto por Javascript, Api y Markup. Pero vamos a analizar esto porque seguro que te habrás dado cuenta que, a diferencia de la definición del stack MEAN, en el stack JAM no estamos definiendo herramientas si no un lenguaje de programación, una plataforma de servicios y un leguaje de marcado de texto. Esto es porque este stack no define las herramientas a utilizar sino más bien el paradigma de desarrollo enfocado al lado del cliente y no al servidor. Por lo que un stack JAM puede formarse por diferntes herramientas siempre que cumplan con los tres pilares del stack:

     Javascript: Para dar vida a la aplicación web en los navegadores donde se ejecute.

     Api: Para obtener todo el contenido externo a la construcción inicial servida al cliente de forma dinámica a través de javascript.

     Markup: Para crear templates con los que construir las estructuras y contenidos estáticos del sitio o aplicación web.

Por tanto, el desarrollo sobre el paradigma JAM no está sujeto a un lenguaje expecífico. Por ejemplo, podemos utilizar el lenguaje Ruby con el framework Jekyll o podemos desarrollar en Javascript con Gatsby.

Bien, tenemos claro que cuando hablamos de JAM nos referimos al paradigma de desarrollo y arquitectura de la aplicación web y no a las herramientas que lo componen. Pero seguimos con la duda de qué es lo que diferencia a las aplicaicones creadas bajo el paradigma JAM de las creadas con arquitecturas stacks más convencionales. Para verlo en detalle vamos mientras definimos a Gatsby.

Y qué es Gatsby

Gatsby es un framework bajo el paradigma JAM para crear aplicaciones estáticas pre-renderizadas. Te permite usar componentes React, pero genera HTML y CSS pre-renderizado para garantizar el tiempo de carga más rápido. Vamos a verlo con más detalle. Primero vamos a definir los tipos de aplicaciones comunes según el momento de su renderizado. En este caso cuando hablamos de renderizado nos refiermos al proceso de montar las paginas html junto con su css y archivos javascript asociados. No al momento de transformar el html en píxeles a mostrar en pantalla.

Tenemos los siguientes tipos:

Server Side Rendering:   Aplicaciones que renderizan los archivos de forma dínamica en el servidor.

Simple Page Aplicación:   Aplicaicones que renderizan de forma dinámica en el lado del cliente.

Aplicaciones estáticas:   Aplicaicones que no renderizan, se sirven mediante un endPoint tal cual fueron desplegadas.

Aplicaicones híbridas:   Aplicaciones que, primero sirven contenido estatico que no ha sido renderizado para despues hidratar con javascript para convertirla en una web con vida.

Las primeras, SSR, han sido las que han predomintado desde los inicios hasta hace relativamente poco. De hecho hoy en día es muy común encontrarse con este tipo de aplicaciónes. Por ejemplo, WordPress, ocupa sobre el 30 % de todas páginas y aplicaciones web de todo el mundo. Y WordPress es una herramienta para crear contenido dináminco desde el servidor. A grandes rasgos, cuando el cliente hace una petición al servidor, éste primero procesa la petición, recoge el contenido de la base de datos, une los templates html y los datos de la BD para montar el archivo html y lo devuelve. Esto, por un lado, es una operación que tiene un coste determinado sobre los recursos del servidor que limita la capacidad y, por otro lado, produce un tiempo de espera para el cliente. Por lo tanto podría tener un gran coste cuando, por ejemplo, nuestro blog empieza a tener un gran número de visitas.

Las segundas, SPA, son aplicaciones que descargan el trabajado de renderizado y montaje al servidor para producirse en el cliente. Cuando el cliente accede al sitio/aplicación web, se le devuelve un index.html con los links y scripts necesarios para montar la aplicación en el cliente. Esto libera al servidor del montaje dinámico de la web para centrarse en servir el contenido mediante un API. Pero esto supone que la página no estará disponible hasta que no se cargue y ejecuten los archivos javascript que contiene la lógica de la aplicación. Además este tipo de aplicaciones no suelen tener un buen SEO ya que los robots no interpretan bien el javascript por lo que no terminan viendo la aplicación termniada. Por tanto no es una buena opción si queremos tener un blog ya que no indexará bién en los buscadores.

Las aplicaciones híbridas son las aplicaciones que primero sirven archivos estáticos pre-renderizado para que la carga se lo más rápida posible para despues ir cargando los archivos javascript que contiene la lógica de la aplicación, cuando el javascript está disponible la pagina se "hidrata" pasando a convertirse en una SPA. De este modo se consigue aunar lo mejor de los dos tipos. Ésta permitiría poder construir, por ejemplo, nuestro blog con unos tiempos de carga muy pequeños, con un buen SEO y contar con toda la potencia de las SPA. Por aclarar, la definición hidratar viene de la traducción directa de hydrate. Pero quizás deberíamos traducirla como refrescar. Así, cuando decimos que la página se hidrata para convertirse en una SPA lo que queremos decir es que la página se refresca conectando los nodos del shadowDOM de React que se acaba de crear con los nodos del DOM que ya existen en la pantalla y así, sin que el visitante se de cuenta, hemos pasado de una página estatica a una SPA.

Lógicamente esto es a grandes rasgos. Si nos adentramos en cada uno no son tan blanco y negro. Los SSR también sirven contenido estático. Las SPA también pueden servirse como parte de una aplicación SSR al igual que las aplicaciones híbridas.

Pero también, una aplicación SPA puede servirse desde un servidor de páginas estáticas como también puede servirse una aplición híbrida desde el mismo tipo de servidor. Los servidores de páginas estáticas, al no tener una aplicación consumiendo recursos dentro de él, supone menos coste que una SSR. Además, una aplicación híbrida que se sirve desde una CDN ( Red de entrega de contenidos) tendrá unos tiempos mejores que las SPA y las SSR.

Por lo tanto Gatsby es un framework para crear aplicaciones híbridas, construidas en Reactjs que pueden ser servidas por una CDN.

En este artículo hemos visto, a un nivel conceptual, qué es Jamstack, qué es Gatsby y mediante ejemplos, cuando utilizarlo. En el siguiente artículo vermos en detalle Gatsby, su estructura y cómo trabaja.