Resumen del libro 'Modern Web Development on the JAMstack'

Este fin de semana he terminado de leer el libro Modern Web Development on the JAMstack.

Puedes leer otras criticas del libro en Goodreads.

Netlify

Una cosa que considero importante a tener en cuenta:

  • Netlify esta detrás del concepto JAMstack.
  • Los autores del libro trabajan en Netlify.
  • Netlify organiza las conferencias Jamstack Conf (este año en tres ciudades distintas: San Francisco, NY, London).

De hecho JAMstack es un montón de tecnologías bajo un nombre molón, como en su momento lo fue Ajax, PWA o RWD. La diferencia es que Netlify es parte interesada porque su negocio es dar servicios a empresas que quieren usar este tipo de tecnología. No me malintepreteis, su plataforma mola mucho, pero es cuanto menos curioso: primero creo la necesidad (real o no) y luego te vendo el producto que lo soluciona.

Si has leido algo sobre JAMstack, os podeís saltar los capítulos del 1 al 5.

IMHO: basicamente te venden la idea y realmente no dicen nada nuevo.

Resumen

La idea principal es pasar de esto:

Client <-> Web Server (Apache) <-> Application Server (Laravel) <-> API|ORM <-> BD

A esto:

Client <-> CDN (static files)

A continuación paso a explicarlo en detalle:

Build de la app

Cuando se produce cualquier cambio en el proyecto se ejecuta un build en el servidor de CI/CD.

Un build se puede generar por:

  • Un webhook: un CMS Headless realiza una llamada a un webhook cuando un usuario ha guardado un dato nuevo.
  • Un commit: un desarrollador sube un cambio a la rama master.
  • etc.

Static Site Generator

El job build se encarga de construir el proyecto con un "Static Site Generator" (Gatsby, Hugo, Nuxt, hay una lista enorme en https://www.staticgen.com). Este job se encarga de crear los HTML, CSS, JS y demás assets del proyecto.

Importante: realmente no son 100% estáticos.

Por ejemplo Gatsby utiliza componentes React y Nuxt trabaja con componentes Vue. Esto añade una capa de interacción al site: puedes hacer llamadas Ajax, puedes usar un state management (Redux o Vuex) para los datos y obviamente puedes separar la lógica de la presentación gracias a los componentes.

Datos

Cuando el "Static Site Generator" construye el proyecto, tiene que sacar los datos de algun sitio. Las opciones pueden ser un CMS headless, una API, ficheros estáticos, etc.

CDN

El job "deploy" se encarga simplemente de subir los assets a un CDN.

Y ya no hay mas pasos :)

Capítulo 6

Lo interesante del libro es el capítulo 6.

En este capítulo describen un caso real: Smashing Magazine paso de un arquitectura monolítica (Wordpress + Ruby on Rails + Shopify) a una arquitectura serveless con la ayuda de Netlify.

Alert spoiler: no sé si este caso de uso se podrá utilizar para otro tipo de proyectos. Me explico: Smashing Magazine es un blog (muy grande) con un sistema de suscripción y una tienda online.

No usaron una tecnología en concreto, sino que han tenido que usar varias librerias y servicios externos, ademas crear algunas otras desde cero (siempre con Netlify de la mano).

¿Qué Static Site Generator usan?

  • Hugo. Basicamente porque cada build tiene que crear MILES de artículos, y Hugo era quien mejor performance les ha dado.

¿Cómo gestionan los datos?

  • Usan un Headless CMS llamado Netlify CMS conectado a un repositorio Git.

¿Cómo han implementado la tienda online?

¿Y el buscador?

  • Algolia (que incluso tienen componentes para React, Vue, Angular, Android, iOS).

¿Y la identidad de los usuarios?

  • GoTrue (una librería Netlify).

¿Y los comentarios?

  • GoTell (otra librería Netlify)

¿Y el envio de correos?

¡Pero no todo se puede ejecutar en el cliente!. ¿Y la seguridad?

  • Para algunas features (por ejemplo las suscripciones) han usado Netlify Functions (un wrapper de AWS Lambda integrado con los servicios de Netlify).