Patrones de renderizado de Jamstack: la evolución

 

 

 

  • SmashingConf Nueva York 2024
  • ¡Registro!

  • Índice
    1. Funcionalidades dinámicas en Jamstack
    2. Representación persistente distribuida (DPR)
    3. Generación estática diferida (DSG)
    4. En resumen
      1. Lecturas adicionales sobre la revista Smashing

    En este artículo, Ekene Eze comparte sus pensamientos sobre la dirección de la web en 2022 y qué soluciones podemos esperar que surjan en el ecosistema para mejorar significativamente la experiencia Jamstack.

     

    En los primeros días de Jamstack, los desarrolladores lo usaban principalmente para sitios estáticos y optaban por un marco de interfaz más detallado como Vue y React cuando necesitaban realizar operaciones más sofisticadas como la representación del lado del servidor en aplicaciones web. La necesidad de agregar funcionalidades dinámicas a las aplicaciones web nunca desapareció, pero eso no nos hizo apreciar menos Jamstack. Nos encantó lo que proponía y el valor que aportaba. Las páginas web están disponibles instantáneamente para los usuarios y los desarrolladores pueden crear sitios web fácilmente e implementarlos más rápido. Los usuarios están contentos, los desarrolladores están contentos; es una situación en la que todos ganan.

    Luego vinieron los generadores de sitios estáticos que mejoraron las cosas al agregar un proceso de compilación al flujo anterior de un sitio estático, lo que significaba que todos los activos del sitio fueron generados previamente por un servidor de compilación (no en una máquina local) y luego implementados. Este fue un paso adelante para mejorar la experiencia de los desarrolladores de Jamstack y, en consecuencia, la popularidad de este modelo. Los desarrolladores podrían crear sitios Jamstack con un generador de sitios estáticos como Gatsby , enviar el proyecto a un sistema de control de versiones como Github e implementarlo en un servicio de alojamiento como Netlify , que proporciona un flujo de trabajo que reconstruirá el sitio cuando haya una actualización del proyecto.

    Todo parecía genial y todos estábamos mejor por ello.

    Pero como cualquier otra tecnología, Jamstack comenzó a evolucionar a medida que seguía creciendo la necesidad de funcionalidades más sofisticadas. Como "sitio estático", un sitio Jamstack estaba limitado en las cosas que podía hacer y la gente no se quedaba callada al respecto. De repente, parecía que Jamstack era un modelo incompleto que no podía usarse a escala. Las preocupaciones planteadas se referían principalmente a la incapacidad de realizar operaciones del lado del servidor y la duración de los tiempos de construcción en sitios Jamstack más grandes. Esto no sentó bien a la comunidad de Jamstack y comenzamos a "extender" Jamstack para resolver este nuevo desafío, que originalmente no estaba destinado a resolver.

     

    Funcionalidades dinámicas en Jamstack

    Si bien Gatsby hizo muchos avances en la forma en que creamos y actualizamos sitios Jamstack con características como compilaciones incrementales, Next.js introdujo la renderización del lado del servidor con getServerSideProps():

    function Page({ data }) { // Render data...}// This gets called on every requestexport async function getServerSideProps() { const res = await fetch(`https://.../data`) const data = await res.json() // Pass data to the page via props return { props: { data } }}export default Page

    Al mismo tiempo que se mantiene la vieja generación estática con getStaticProps():

    // posts will be populated at build time by getStaticProps()function Blog({ posts }) { return ( ul {posts.map((post) = ( li{post.title}/li))} /ul)}export async function getStaticProps() { const res = await fetch('https://.../posts') const posts = await res.json( return { props: { posts, }, }}export default Blog

    Esto dio a los desarrolladores la idea de un enfoque híbrido para crear sitios Jamstack. De repente, podrías crear sitios Jamstack que pudieran representar diferentes páginas con diferentes patrones de representación. Por ejemplo, su /aboutpágina podría generarse estáticamente mientras su /cartpágina se procesa en el lado del servidor. Sin embargo, persistía el problema de los largos tiempos de construcción. Pero no por mucho.

    Con la regeneración estática incremental (ISR) , Next.js también hizo posible que las páginas se generaran bajo demanda y se almacenaran en caché para solicitudes posteriores. Esto significaba que los desarrolladores podían tener un sitio con 10.000 páginas y solo generar 100 páginas en el momento de la construcción. Todas las demás páginas se generarán dinámicamente bajo demanda y se almacenarán en caché para solicitudes posteriores, lo que efectivamente eliminará la preocupación por los tiempos de compilación prolongados.

    function Blog({ posts }) { return ( ul {posts.map((post) = ( li key={post.id}{post.title}/li))} /ul)}export async function getStaticProps() { const res = await fetch('https://.../posts') const posts = await res.json() return { props: { posts, }, revalidate: 10, // In seconds }}export async function getStaticPaths() { const res = await fetch('https://.../posts', {limit: 100}) const posts = await res.json() // Get the paths we want to pre-render based on posts const paths = posts.map((post) = ({ params: { id: post.id }, })) return { paths, fallback: 'blocking' }}export default Blog

    Representación persistente distribuida (DPR)

    En abril de 2021, Netlify anunció un nuevo patrón de renderizado llamado Representación persistente distribuida . La idea era eliminar el bit de revalidación de ISR y hacer que cualquier página que se represente después de la compilación inicial sea parte permanente de esa compilación. Sin revalidación. Si desea volver a representar esa página en el futuro, deberá activar una nueva compilación. Según la publicación del anuncio , este patrón no comprometerá el principio Jamstack de despliegues atómicos inmutables.

    Junto con el anuncio del DPR, Netlify también lanzó creadores bajo demanda : un tipo especial de función sin servidor que genera contenido bajo demanda, lo almacena en caché en el borde y funciona en todos los marcos. Esto trajo capacidades similares a ISR a todos los demás generadores de sitios estáticos y metamarcos.

    const { builder } = require('@netlify/functions');async function myfunction(event, context) { // logic to generate the required content}exports.handler = builder(myfunction);

    Esto abrió más oportunidades para que los generadores de sitios estáticos como Gatsby entraran en este patrón de entrega de páginas web con su propia adaptación del concepto llamado Generación estática diferida (DSG). Eleventy también lanzó el complemento Eleventy Serverless que se basa en el concepto DPR para admitir este patrón de representación para los desarrolladores.

    Generación estática diferida (DSG)

    Como se mencionó, Gatsby adaptó el concepto DPR para crear un patrón de representación DSG personalizado que permite a los desarrolladores posponer páginas no críticas y solo generar el contenido necesario en el momento de la compilación. Al igual que con ISR, las páginas diferidas se generan bajo demanda y se almacenan en caché. Todas las solicitudes posteriores de esas páginas se atienden desde la memoria caché.

    // The rest of your page, including imports, page component page query etc.export async function config() { // Optionally use GraphQL here return ({ params }) = { return { defer: true, } }}

    El objetivo de esta publicación es echar un vistazo a la evolución de los patrones de renderizado de Jamstack, dónde empezamos y dónde nos encontramos. Por el momento, hemos llegado muy lejos de donde empezamos, y con razón. Pero personalmente, pienso, ¿deberíamos habernos quedado con la idea inicial de un sitio Jamstack? Uno en el que no tuviéramos que preocuparnos por las funcionalidades dinámicas. Estamos en 2022 y hay muchos matices en torno a las diferencias entre un sitio Jamstack y una aplicación React normal.

    En resumen

    Jamstack ha pasado de simplemente generar e implementar activos estáticos a manejar funcionalidades altamente dinámicas con patrones de renderizado avanzados y funciones sin servidor.

    Sí, ha habido avances en los patrones de renderizado de Jamstack y han seguido mejorando hasta la fecha. Pero, en consecuencia, estas mejoras agregaron más complejidad a un proceso que de otro modo sería simple. Al continuar ampliando Jamstack para dar cuenta de más casos de uso, corremos el riesgo de complicarlo demasiado.

    Pero como en cualquier otro espacio, esperamos ver mejoras continuas. 2021 vio el surgimiento y dominio de metaframeworks como Astro , Slinkity y Remix , todos tratando de enviar menos JavaScript al navegador.

    Esta parece ser la dirección que está tomando la web en 2022, y esperamos ver surgir más soluciones en el ecosistema para mejorar significativamente la experiencia Jamstack. La aparición de componentes de servidor React en React, Vite como una alternativa más rápida para Webpack y Babel, la informática Edge utilizada por empresas como Remix, HTML Streaming, etc., son soluciones prometedoras que continúan ganando popularidad y adopción. Y sólo podemos suponer que las cosas mejorarán y serán más interesantes a medida que estas tecnologías penetren en la infraestructura web existente. Es seguro decir que los mejores días de Jamstack aún están por delante.

    La práctica moderna de tendencias web para crear sitios altamente optimizados es enviar menos JavaScript. Aquí es donde tecnologías como Remix reclaman dominio. Es interesante ver cómo continúa evolucionando el espacio Jamstack y, personalmente, estoy ansioso por saber cuál será el siguiente paso.

    Si está creando un sitio Jamstack hoy, estos son los patrones de renderizado disponibles actualmente para usted:

    • Las páginas de generación estática
      se procesan una vez en el momento de la compilación.
    • Las páginas de representación del lado del servidor
      se generan por solicitud.
    • Representación diferida (ISR/DPR/DSG)
      Las páginas críticas se generan primero en el momento de la compilación, y las páginas no críticas se generan según demanda y se almacenan en caché.

    Lecturas adicionales sobre la revista Smashing

    • Una guía completa para ISR con Next.js , Lee Robinson
    • Jamstack CMS: el pasado, el presente y el futuro , Mike Neumegen
    • Herramientas de aprendizaje interactivas para desarrolladores front-end , Louis Lazaris
    • Cómo crear un sitio de WordPress sin cabeza en JAMstack , Sarah Drasner y Geoff Graham

    (vf, il, yk)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

    Patrones de renderizado de Jamstack: la evolución

    Patrones de renderizado de Jamstack: la evolución

    SmashingConf Nueva York 2024 ¡Registro! Índice Funcionalidades dinámicas en Jamstack

    programar

    es

    https://aprendeprogramando.es/static/images/programar-patrones-de-renderizado-de-jamstack-la-evolucion-1138-0.jpg

    2024-04-04

     

    Patrones de renderizado de Jamstack: la evolución
    Patrones de renderizado de Jamstack: la evolución

    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