La evolución de Jamstack

 

 

 


Índice
  1. Compilando la interfaz de usuario
    1. Frontends desacoplados
  2. Extrayendo datos según sea necesario
  3. Jamstack en 2021 y más allá
    1. 1. Representación persistente distribuida (DPR)
    2. 2. Transmisión de actualizaciones desde la capa de datos
    3. 3. La colaboración entre desarrolladores se generaliza
  4. Habilitación de casos de uso dinámicos y de escala
    1. Lecturas adicionales y referencias

Las bases de datos orientadas a la web, marcos como Nuxt y Next.js e incluso enfoques sin marco están haciendo evolucionar Jamstack, pero los principios básicos son más poderosos que nunca.

 

Han pasado cinco años desde que presenté por primera vez la idea de la arquitectura Jamstack en SmashingConf en San Francisco 2016, una charla inspirada en muchas conversaciones con colegas y amigos de la industria. En ese momento, la idea de desacoplar fundamentalmente la capa web front-end de la capa de lógica empresarial back-end era solo una tendencia inicial y aún no era un enfoque arquitectónico con nombre.

La nueva pila de front-end. Javascript, API y marcado. Una presentación de 2016 de Matt Biilmann. Ver en Vimeo

Los generadores de sitios estáticos estaban surgiendo como una opción real para crear sitios más grandes basados ​​en contenido, pero todo el ecosistema que los rodeaba era incipiente y los principales generadores eran puras herramientas de código abierto sin presencia comercial. Las aplicaciones de una sola página fueron la base de algunas aplicaciones web a gran escala, como Gmail, pero el enfoque típico para crearlas todavía estaba centrado en el backend.

Un avance rápido hasta 2020, Jamstack llegó a la corriente principal y vimos a millones de desarrolladores y marcas importantes como Unilever , Nike y PayPal adoptar la arquitectura. Iniciativas vitales como el Proyecto de seguimiento de Covid pudieron escalar de 0 a 2 millones de solicitudes de API en Jamstack. Los marcos como Nuxt se convirtieron en negocios comerciales y celebramos a las grandes empresas públicas como Microsoft y Cloudflare cuando lanzaron las primeras ofertas de Jamstack.

 

A medida que el espacio comercial se ha calentado y la comunidad de desarrolladores ha crecido, también ha habido más ruido e incluso estamos empezando a probar los límites de las mejores prácticas de Jamstack . Parece el momento adecuado para revisar la visión original que algunos de nosotros teníamos hace cinco años y mirar hacia adelante y ver lo que significarán los cambios en el panorama tecnológico para el futuro de la arquitectura Jamstack y la web.

Comencemos revisando rápidamente los principios básicos que han hecho que la arquitectura sea popular.

Compilando la interfaz de usuario

En la arquitectura Jamstack, la interfaz de usuario está compilada . El objetivo es hacer el trabajo correcto en el momento adecuado, con preferencia por hacer la mayor cantidad de trabajo posible con anticipación. Muchas veces, se puede renderizar previamente todo el sitio, y tal vez ni siquiera se requiera un backend una vez implementado.

Frontends desacoplados

Desacoplar el frontend de los servicios y plataformas backend impone un contrato claro sobre cómo se comunica su interfaz de usuario con el resto del sistema. Esto se basa en la simplicidad : su interfaz tiene una superficie de contacto limitada con cualquier cosa fuera de sí misma, lo que hace que sea menos complicado comprender cómo los cambios externos afectarán su funcionamiento.

Extrayendo datos según sea necesario

Por supuesto, no todo se puede renderizar previamente, y la arquitectura Jamstack es capaz de ofrecer aplicaciones web dinámicas y personalizadas, así como contenido más consistente a nivel global. Solicitar datos desde la interfaz puede impulsar algunas aplicaciones ricas y dinámicas.

Un buen ejemplo es la interfaz de nuestra propia interfaz de usuario de Netlify , que en sí misma es una aplicación Jamstack creada y ejecutada en Netlify. Precompilamos el shell de una aplicación y luego utilizamos solicitudes asincrónicas para acceder a nuestra API y cargar datos sobre nuestros usuarios y sus sitios. Ya sea que esté utilizando REST, GraphQL o WebSockets, si está precompilando la mayor cantidad posible de interfaz de usuario y cargando datos para brindarles a sus usuarios una experiencia dinámica y personalizada , entonces estará enviando la arquitectura Jamstack.

Jamstack en 2021 y más allá

Hay más innovación que nunca en el ecosistema Jamstack. Se puede ver una rápida evolución de los servicios back-end, las herramientas para desarrolladores y las tecnologías del lado del cliente que se combinan para permitir a los equipos de desarrollo crear experiencias para la web que habrían parecido fuera de su alcance hace sólo un par de años.

Quiero señalar tres tendencias que veo que se perfilan para los desarrolladores de Jamstack en el futuro cercano:

1. Representación persistente distribuida (DPR)

Más que nada, la simplicidad inherente de Jamstack ha hecho que el proceso de creación e implementación de aplicaciones web sea mucho más fácil de entender. Las actualizaciones de código y contenido se pueden presentar previamente como implementaciones atómicas y limpias y llevarse hasta el borde, creando sólidas garantías en torno a la confiabilidad y el rendimiento sin la necesidad de administrar una infraestructura compleja.

 

Pero prerenderizar un sitio web más grande también puede significar esperar varios minutos cada vez que hay una nueva implementación. Es por eso que creo que estamos viendo tanta innovación para hacer que las compilaciones sean más inteligentes y rápidas, especialmente para sitios y aplicaciones web más grandes. Tomemos, por ejemplo, la velocidad bruta de esbuild , el nuevo "compilador de JavaScript extremadamente rápido". Esbuild puede completar un paquete de producción que Parcel o Webpack puede tardar más de un minuto en compilar en menos de un segundo . Y cree herramientas como Vite y Snowpack que se apoyan en módulos ES nativos para que el desarrollo local parezca casi instantáneo.

Al igual que los activos generados durante una compilación, los generados por DPR en el momento de la solicitud permanecerían en la caché de CDN hasta que sean invalidados por la finalización exitosa de una nueva implementación. Esto permitiría a los desarrolladores considerar los activos renderizados durante una implementación y aquellos renderizados bajo demanda a partir de solicitudes a funciones DPR contenidas en esa implementación, como todos pertenecientes a la misma implementación atómica lógica. ( Vista previa grande )

En el ecosistema React, algunos marcos más nuevos como Remix o Blitz están comenzando a apoyarse más en el enfoque de "ejecutar todo en un servidor" que todos conocemos en el pasado. Existe el riesgo de recuperar gran parte de la complejidad de la que hemos trabajado para escapar. Las capas de almacenamiento en caché pueden ayudar a que las aplicaciones del lado del servidor tengan más rendimiento, pero los desarrolladores pierden las garantías de implementaciones atómicas que hacen que las aplicaciones Jamstack sean fáciles de entender.

Blitz parece estar moviendo el monolito al frente. Esto puede hacer que las aplicaciones full-stack se puedan ejecutar en plataformas Jamstack típicas, pero sin un desacoplamiento claro entre la capa de experiencia web y la capa de lógica empresarial back-end. Creo que desacoplar el frontend del backend es fundamental para el enfoque Jamstack y es responsable de desbloquear muchos de sus beneficios.

Lo que veo que están ganando un impulso real son los marcos "híbridos" como Next.js , Nuxt.js y SvelteKit que permiten a los desarrolladores mezclar sin problemas páginas pre-renderizadas en el momento de la construcción con otras rutas que se representan a través de funciones sin servidor. El desafío es que las funciones sin servidor (aunque ciertamente escalables) tienen su propio conjunto de implicaciones de rendimiento .

En última instancia, veo que la comunidad avanza hacia un trío extremadamente poderoso que proporciona a los desarrolladores de Jamstack control a nivel de solicitud sobre el perfil de rendimiento de cualquier sitio o aplicación: Recetas faciles y rápidas

  1. Entregar páginas completamente renderizadas previamente en el momento de la construcción,
  2. Entregar páginas dinámicamente a través de funciones sin servidor, o
  3. Creación de páginas bajo demanda que luego persisten como activos CDN estáticos.

Next.js ha trabajado bastante en un concepto de regeneración estática incremental . La idea es garantizar páginas de alto rendimiento combinando funciones sin servidor con diferentes estrategias de almacenamiento en caché como Stale While Revalidate . Si bien la idea de distribuir algunas de las compilaciones con un enfoque bajo demanda que aún incluya sólidas garantías de almacenamiento en caché es una técnica poderosa, a menos que los desarrolladores opten explícitamente por no participar en el enfoque obsoleto mientras se revalida, la garantía de implementación atómica se violará al servir. una combinación de activos obsoletos y nuevos de diferentes implementaciones. Actualmente, los beneficios de ISR también son exclusivos de un marco singular y sólo están profundamente integrados en las ofertas de un único proveedor.

 

En Netlify, vemos muy prometedora la idea de permitir a los desarrolladores representar páginas críticas en el momento de la compilación, mientras se pospone la creación de otras páginas (como publicaciones de blogs más antiguas, por ejemplo) solo cuando y si se solicitan. A este enfoque lo llamamos renderizado persistente distribuido o DPR. Es una arquitectura para compilaciones incrementales que puede ser compatible en casi todos los marcos y generadores de sitios Jamstack, desde 11ty hasta Nuxt y Next.js.

DPR reducirá drásticamente los tiempos de construcción inicial para sitios más grandes, resolviendo una crítica central a la generación de sitios estáticos. En Jamstack.org , abrimos una Solicitud de comentarios para involucrar a toda la comunidad en nuestros esfuerzos por brindar a los desarrolladores más opciones sobre cómo se representan las páginas y, al mismo tiempo, adherirnos estrechamente a los principios que han hecho a Jamstack tan popular. Al darle un nombre a esta arquitectura y refinarla con aportes de la comunidad, podemos ayudar a los desarrolladores de Jamstack a crear patrones a su alrededor, independientemente del marco.

2. Transmisión de actualizaciones desde la capa de datos

Si desarrolla aplicaciones web, probablemente haya seguido la evolución de las bibliotecas de administración estatal a medida que los desarrolladores han creado interfaces web cada vez más complejas utilizando herramientas como React, Vue y Svelte. Pero la gestión estatal ha sido en gran medida una preocupación en el navegador y en la memoria. Básicamente, cada pestaña del navegador tiene su propio estado, pero puede ser bastante complejo conectar el estado del navegador local de su aplicación a los servicios de datos que la impulsan.

Afortunadamente, esto está mejorando a medida que cada vez más servicios admiten suscripciones de datos en tiempo real . Hasura , OneGraph y Supabase ofrecen esta capacidad y solo espero ver una adopción más amplia en todos los proveedores, ya que los almacenes de datos subyacentes se almacenan en caché y se distribuyen en el borde para un rendimiento global rápido. Tomemos como ejemplo las API en expansión de Twillio: ahora no solo ofrecen transmisión de video , sino también “pistas de datos” de transmisión, que pueden usarse para crear aplicaciones de colaboración complejas que se mantienen continuamente sincronizadas entre los participantes.

 

Finalmente, están surgiendo nuevos proveedores que agregan datos a través de servicios back-end. Ya sea que use GraphQL como lenguaje de consulta o no, es realmente convincente imaginar el poder de conectar su interfaz de usuario a un flujo único y estándar de actualizaciones de múltiples API subyacentes.

3. La colaboración entre desarrolladores se generaliza

Jamstack se basa en un flujo de trabajo de Git, un enfoque que se adapta muy bien a equipos de desarrollo más grandes. Pero en el futuro, comenzaremos a ver cómo estas herramientas tradicionalmente centradas en los desarrolladores se expandirán para involucrar a todos en la empresa: desarrolladores, claro, pero también escritores, editores, diseñadores y expertos en SEO.

Cuando piensas en colaboración, tiendes a pensar en ediciones sincrónicas: los múltiples cursores que vuelan alrededor de un documento de Google, por ejemplo. Estamos viendo que ese estilo de colaboración en vivo llega a herramientas CMS como Sanity y herramientas de diseño como Figma. Pero gran parte del trabajo a menudo ocurre de forma asincrónica, y los no desarrolladores tradicionalmente no han disfrutado de las poderosas herramientas que los desarrolladores usan para ramificar, organizar y fusionar cambios sin problemas con una discusión colaborativa adjunta a cada solicitud de extracción .

Al principio de Jamstack, surgieron algunas herramientas CMS inteligentes basadas en git para ayudar a los no desarrolladores a administrar contenido como código, tal vez sin siquiera saber que cada cambio que hacían estaba comprometido con git como un desarrollador que trabaja desde la terminal. Ahora estamos empezando a ver nuevas herramientas que abordan las ediciones visuales de páginas de una manera que sigue siendo compatible con los generadores de sitios Jamstack populares como Gatsby y Next.js. Todo esto reduce el listón de la colaboración para los no desarrolladores y solo veremos que esa tendencia se acelera.

Y no son sólo los no desarrolladores los que se unen a la colaboración: las integraciones profundas entre herramientas están aportando contribuciones más automatizadas a nuestros flujos de trabajo de desarrollo, construcción e implementación. Simplemente explore el historial de comentarios en una solicitud de extracción de GitHub para ver cuántas herramientas están ahora integradas para ejecutar pruebas automatizadas y detectar errores antes de implementarlas.

Las actualizaciones de los documentos de Netlify, por ejemplo, no solo se ajustan a nuestros estándares de código, sino que también se ajustan a nuestros estándares de contenido, lo que garantiza que nos mantengamos coherentes con nuestra guía de estilo para vocabulario, lenguaje y fraseo. Los equipos ahora también pueden vincular fácilmente los presupuestos de rendimiento y los estándares de SEO a cada implementación, nuevamente con alertas y registros vinculados directamente a los problemas de GitHub.

Esperaría ver ese tipo de integraciones explotar en el próximo año, permitiendo que un flujo de trabajo basado en git respalde no solo los cambios de código, sino también el contenido, los datos, los activos de diseño, lo que sea. Las interfaces amigables en estos flujos de trabajo de Git permitirán que más contribuyentes comenten, se comprometan y colaboren y llevarán las herramientas de productividad de los desarrolladores a la corriente principal.

Habilitación de casos de uso dinámicos y de escala

Si bien Jamstack se mantiene fiel a los conceptos centrales de desacoplar el frontend del backend y mantener implementaciones atómicas e inmutables, las nuevas estrategias de construcción y las primitivas informáticas tienen el potencial de desbloquear sitios de escala extremadamente grande y aplicaciones web dinámicas en tiempo real.

Los desarrolladores de Jamstack (y ahora equipos web completos, especialistas en marketing y gerentes de productos) tienen mucho que esperar en este espacio.

Lecturas adicionales y referencias

  • " Cómo el proyecto de seguimiento de COVID aumentó de 0 a 2 millones de solicitudes de API en 3 meses ", Netlify, Blog de Netlify
  • “ Regeneración estática incremental: sus beneficios y sus defectos ”, Cassidy Williams, blog de Netlify
  • " Representación persistente distribuida: un nuevo enfoque Jamstack para compilaciones más rápidas ", Matt Biilmann, Blog de Netlify
  • Glosario , Jamstack.org

(vf, il)

Explora más en

  • pila de mermelada
  • Siguiente.js
  • javascript
  • Sin servidor





Tal vez te puede interesar:

  1. ¿Deberían abrirse los enlaces en ventanas nuevas?
  2. 24 excelentes tutoriales de AJAX
  3. 70 técnicas nuevas y útiles de AJAX y JavaScript
  4. Más de 45 excelentes recursos y repositorios de fragmentos de código

La evolución de Jamstack

La evolución de Jamstack

Índice Compilando la interfaz de usuario

programar

es

https://pseint.es/static/images/programar-la-evolucion-de-jamstack-1093-0.jpg

2024-04-04

 

La evolución de Jamstack
La evolución de Jamstack

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

 

 

Top 20