Un nuevo patrón para Jamstack: renderizado segmentado

 

 

 

  • Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX
  • Anuncie en la revista Smashing

  • Índice
    1. Felicitaciones por tu nuevo trabajo
    2. Las muchas formas de representar una página web con marcos de JavaScript modernos
      1. RSC, RSS, SSG… aclaremos qué son
      2. CSR: El feo problema del cargador
      3. SSR por solicitud: mordido por el primer byte
      4. Representación estática: la clave del problema del huésped rico/cliente pobre
    3. Profundice en el renderizado segmentado
      1. El renderizado estático ofrece el mejor rendimiento pero es menos flexible
      2. Desacoplamiento de URL y variación de página
      3. Una nota sobre los hosts "estáticos"
      4. Fácil redirección con middlewares Next.js
      5. Cherry On The Top: reescritura de URL
    4. Resumen
    5. ¿Que sigue? ¡Aún más rendimiento!
      1. Más recursos sobre este tema
      2. Lecturas adicionales sobre la revista Smashing

    Entre todas las arquitecturas posibles para renderizar un sitio web, la renderización estática es la de mayor rendimiento. Sin embargo, solo se aplica al contenido público y genérico. ¿O es eso? En este artículo, ampliaremos los límites del renderizado estático y aprenderemos cómo aplicarlo al contenido personalizado. Este nuevo patrón se llama "Renderizado segmentado" y cambiará el juego Jamstack para siempre.

     

    Si cree que la representación estática se limita al contenido público genérico que es el mismo para todos los usuarios de su sitio web, definitivamente debería leer este artículo.

    La representación segmentada es un nuevo patrón para Jamstack que le permite personalizar el contenido de forma estática, sin ningún tipo de representación del lado del cliente o representación del lado del servidor por solicitud. Hay muchos casos de uso: personalización, internacionalización, tematización, multi-tenencia, pruebas A/B…

    Centrémonos en un escenario muy útil para los propietarios de blogs: el manejo de contenido pago.

    Felicitaciones por tu nuevo trabajo

    ¡Guau, te acaban de ascender! Ahora eres el "Jefe de rendimiento" de Repairing Magazine, el competidor más serio de Smashing Magazine. Repairing Magazine tiene un modelo de negocio muy peculiar. Los chistes ingeniosos de cada artículo solo son visibles para los usuarios pagos.

    ¿Por qué el programador cruzó la calle?

    Apuesto a que pagarías para saber la respuesta.

    Su trabajo para hoy es implementar esta característica con el mejor rendimiento posible. Veamos cómo puedes hacer eso. Sugerencia: vamos a introducir un nuevo patrón llamado "Representación segmentada".

    Las muchas formas de representar una página web con marcos de JavaScript modernos

    La popularidad de Next.js se debe a su dominio de la "Trifuerza del renderizado": la capacidad de combinar el renderizado del lado del cliente, el renderizado del servidor por solicitud y el renderizado estático en un único marco.

    RSC, RSS, SSG… aclaremos qué son

    La interfaz de usuario de Repairing Magazine se basa en una biblioteca JavaScript moderna, React. Al igual que otras bibliotecas de UI similares, React proporciona dos formas de representar contenido: del lado del cliente y del lado del servidor.

    La representación del lado del cliente (CSR) ocurre en el navegador del usuario. En el pasado, habríamos usado jQuery para realizar CSR.

    La representación del lado del servidor ocurre en su propio servidor, ya sea en el momento de la solicitud (SSR) o en el momento de la compilación (estática o SSG). SSR y SSG también existen fuera del ecosistema de JavaScript. Piense en PHP o Jekyll, por ejemplo.

    Veamos cómo se aplican esos patrones a nuestro caso de uso.

    CSR: El feo problema del cargador

    La representación del lado del cliente (CSR) usaría JavaScript en el navegador para agregar chistes ingeniosos después de cargar la página. Podemos usar "fetch" para obtener el contenido de los chistes y luego insertarlos en el DOM.

    // server.jsconst wittyJoke = "Why did the programmer cross the road? There was something he wanted to C.";app.get("/api/witty-joke", (req) = { if (isPaidUser(req)) { return { wittyJoke }; } else { return { wittyJoke: null }; }});// client.jsconst ClientArticle = () = { const { wittyJoke, loadingJoke } = customFetch("/api/witty-jokes"); // THIS I DON’T LIKE... if (loadingJoke) return pUgly loader/p; return ( p {wittyJoke ? wittyJoke : "You have to pay to see jokes. Humor is a serious business."} /p );};

    La CSR implica cálculos redundantes del lado del cliente y muchos cargadores desagradables.

     

    Funciona, pero ¿es el mejor enfoque? Su servidor tendrá que servir chistes ingeniosos para cada lector. Si algo hace que el código JavaScript falle, el usuario pago no tendrá su dosis de diversión y podría enojarse. Si los usuarios tienen una red lenta o una computadora lenta, verán un cargador feo mientras se descarga su chiste. Recuerde que la mayoría de los visitantes navegan a través de un dispositivo móvil.

    Este problema solo empeora a medida que aumenta la cantidad de llamadas a la API. Recuerde que un navegador sólo puede ejecutar un puñado de solicitudes en paralelo (normalmente 6 por servidor/proxy). La representación del lado del servidor no está sujeta a esta limitación y será más rápida cuando se trata de recuperar datos de sus propios servicios internos.

    SSR por solicitud: mordido por el primer byte

    La representación del lado del servidor (SSR) por solicitud genera el contenido bajo demanda, en el servidor. Si se paga al usuario, el servidor devuelve el artículo completo directamente como HTML. De lo contrario, devuelve el artículo insulso sin nada de diversión.

    // page.js: server-codeasync function getServerSideProps(req) { if (isPaidUser(req)) { const { wittyJoke } = getWittyJoke(); return { wittyJoke }; } else { return { wittyJoke: null }; }}// page.js: client-codeconst SSRArticle = ({ wittyJoke }) = { // No more loader! But... // we need to wait for "getServerSideProps" to run on every request return ( p {wittyJoke ? wittyJoke : "You have to pay to see jokes. Humor is a serious business."} /p );};

    SSR elimina los cálculos del lado del cliente, pero no el tiempo de carga.

    Ya no dependemos del JavaScript del lado del cliente. Sin embargo, no es energéticamente eficiente procesar el artículo para todas y cada una de las solicitudes. El tiempo hasta el primer byte (TTFB) también aumenta porque tenemos que esperar a que el servidor termine su trabajo antes de comenzar a ver algún contenido.

    ¡Hemos reemplazado el feo cargador del lado del cliente con una pantalla en blanco aún más fea! ¡Y ahora incluso pagamos por ello!

    La estrategia de control de caché "obsoleta mientras se revalida" puede reducir el problema de TTFB al ofrecer una versión almacenada en caché de la página hasta que se actualice. Pero no funcionará de inmediato para contenido personalizado, ya que solo puede almacenar en caché una versión de la página por URL sin tener en cuenta las cookies y no puede manejar los controles de seguridad necesarios para ofrecer contenido pago.

    Representación estática: la clave del problema del huésped rico/cliente pobre

    En este punto, se encuentra con lo que yo llamo el problema del “huésped rico/cliente pobre”: sus usuarios premium obtienen el peor rendimiento en lugar de obtener el mejor.

    Por diseño, la representación del lado del cliente y la representación del lado del servidor por solicitud implican la mayor cantidad de cálculos en comparación con la representación estática, que ocurre solo una vez en el momento de la compilación.

    El 99% de los sitios web que conozco elegirán CSR o SSR y sufrirán el problema de huésped rico/cliente pobre.

     

    Unámonos al 1% y hagamos ricos a nuestros clientes nuevamente. (Crédito de la imagen: Pexels ) ( Vista previa grande )

    Profundice en el renderizado segmentado

    El renderizado segmentado es simplemente una forma más inteligente de realizar renderizado estático. Una vez que comprenda que se trata de almacenar en caché los renderizados y luego obtener el renderizado en caché correcto para cada solicitud, todo encajará en su lugar.

    El renderizado estático ofrece el mejor rendimiento pero es menos flexible

    Static Site Generation (SSG) genera el contenido en el momento de la compilación. Ese es el enfoque más eficaz porque renderizamos el artículo de una vez por todas. Luego se sirve como HTML puro.

    Esto explica por qué el renderizado previo en el momento de la construcción es una de las piedras angulares de la filosofía Jamstack. Como “Jefe de Rendimiento” recién ascendido, ¡eso es definitivamente lo que quieres!

    A partir de 2022, todos los marcos de Jamstack tienen aproximadamente el mismo enfoque de renderizado estático:

    • calcula una lista de todas las URL posibles;
    • renderizas una página para cada URL.
    const myWittyArticles = [ "/how-to-repair-a-smashed-magazine", "/segmented-rendering-makes-french-web-dev-famous", "/jamstack-is-so-2022-discover-haystack",];

    Resultado del primer paso del renderizado estático: calcular un conjunto de URL que prerenderizará. Para un blog, suele ser una lista de todos sus artículos. En el paso 2, simplemente representa cada artículo, uno por URL.

    Esto significa que una URL equivale estrictamente a una versión de la página. No puede tener una versión paga y otra gratuita del artículo en la misma URL, incluso para diferentes usuarios. La URL /how-to-repair-a-smashed-magazineentregará el mismo contenido HTML a todos, sin ninguna opción de personalización. No es posible tener en cuenta las cookies de solicitud.

    La representación segmentada puede ir un paso más allá y representar diferentes variaciones para la misma URL. Aprendamos cómo.

    Desacoplamiento de URL y variación de página

    La solución más ingenua para permitir contenido personalizado es agregar un nuevo parámetro de ruta a la URL, por ejemplo, "con chistes" versus "soso".

    const premiumUrl = "/with-jokes/how-to-repair-a-smashed-magazine";const freeUrl = "/bland/how-to-repair-a-smashed-magazine";

    Una implementación con Next.js se verá más o menos así:

    async function getStaticPaths() { return [ // for paid users "/with-jokes/how-to-repair-a-smashed-magazine", // for free users "/bland/how-to-repair-a-smashed-magazine", ];}async function getStaticProps(routeParam) { if (routeParam === "with-jokes") { const { wittyJoke } = getWittyJoke(); return { wittyJoke }; } else if (routeParam === "bland") { return { wittyJoke: null }; }}

    La primera función calcula 2 URL para el mismo artículo, una divertida y otra insípida. La segunda función capta la broma, pero sólo para la versión paga.

     

    Genial, tienes 2 versiones de tus artículos. Podemos comenzar a ver los "Segmentos" en "Representación segmentada": usuarios pagos versus usuarios gratuitos, con una versión renderizada para cada segmento.

    Pero ahora tienes un nuevo problema: ¿cómo redirigir a los usuarios a la página correcta? Fácil: redirija a los usuarios a la página correcta, ¡literalmente! ¡Con servidor y todo!

    Puede parecer extraño al principio que necesites un servidor web para lograr una representación estática eficiente. Pero créame en esto: la única forma de lograr el mejor rendimiento para un sitio web estático es optimizando el servidor.

    Una nota sobre los hosts "estáticos"

    Si vienes del ecosistema Jamstack, es posible que estés enamorado del hosting estático. ¿Qué mejor sensación que enviar algunos archivos y poner en funcionamiento su sitio web en GitHub Pages? ¿O alojar una aplicación completa directamente en una red de entrega de contenido (CDN)?

    Sin embargo, "alojamiento estático" no significa que no haya ningún servidor. Significa que no puedes controlar el servidor. Todavía hay un servidor encargado de señalar cada URL al archivo estático correcto.

    El alojamiento estático debe verse como una opción limitada pero económica y eficaz para alojar un sitio web personal o la página de inicio de una empresa. Si desea ir más allá de eso, deberá tomar control del servidor, al menos para manejar cosas como la redirección basada en las cookies o encabezados de solicitud.

    Sin embargo, no es necesario llamar a un experto en backend. No necesitamos ningún tipo de cálculo sofisticado. Un servidor de redirección muy básico que pueda comprobar si el usuario recibe pago será suficiente.

    Buenas noticias: los hosts modernos como Vercel o Netlify implementan Edge Handlers, que son exactamente lo que necesitamos aquí. Next.js implementa esos controladores de borde como "middlewares", por lo que puedes codificarlos en JavaScript.

    El "Edge" significa que los cálculos se realizan lo más cerca posible del usuario final, en lugar de tener unos pocos servidores centralizados grandes. Puede verlos como los muros exteriores de su infraestructura central. Son excelentes para la personalización, que a menudo está relacionada con la ubicación geográfica real del usuario.

    Fácil redirección con middlewares Next.js

    Los middlewares Next.js son muy rápidos y fáciles de codificar. A diferencia de los servidores proxy de la nube como AWS Gateway o las herramientas de código abierto como Nginx, los middlewares se escriben en JavaScript y utilizan estándares web, concretamente la API de recuperación .

    En la arquitectura de "Representación segmentada", los middlewares simplemente se encargan de señalar cada solicitud del usuario a la versión correcta de la página:

    import { NextResponse } from "next/server";import type { NextRequest } from "next/server";async function middleware(req: NextRequest) { // isPaidFromReq can read the cookies, get the authentication token, // and verify if the user is indeed a paid member or not const isPaid = await isPaidFromReq(req); const routeParam = isPaid ? "with-jokes" : "bland"; return NextResponse.redirect( `/${routeParam}/how-to-repair-a-smashed-magazine` );}

    Un middleware que implementa renderizado segmentado para usuarios gratuitos y pagos.

     

    Bueno, eso es todo. Su primer día como “Jefe de desempeño” ha terminado. ¡Tiene todo lo que necesita para lograr el mejor rendimiento posible para su extraño modelo de negocio!

    Por supuesto, puedes aplicar este patrón a muchos otros casos de uso: contenido internacionalizado, pruebas A/B, modo claro/oscuro, personalización… Cada variación de tu página constituye un nuevo “Segmento”: usuarios franceses, personas que prefieren la oscuridad. tema o usuarios pagos.

    Cherry On The Top: reescritura de URL

    Pero bueno, ¡usted es el “Jefe de desempeño”, no el “Promedio de desempeño”! ¡Quieres que tu aplicación web sea perfecta, no solo buena! Sin duda, su sitio web es muy rápido en todas las métricas, pero ahora las URL de sus artículos se ven así:

    /bucket-A/fr/light/with-jokes/3-tips-to-make-an-url-shorter

    Eso no es muy atractivo... El renderizado segmentado es genial, pero el usuario final no tiene que ser consciente de sus propios "segmentos". El castigo por un buen trabajo es más trabajo, así que agreguemos un toque final: en lugar de usar redireccionamientos de URL, use reescrituras de URL. Son exactamente lo mismo, excepto que no verá parámetros en la URL.

    // A rewrite won’t change the URL seen// by the end user = they won’t see the "routeParam"return NextResponse.rewrite(`/${routeParam}/how-to-repair-a-smashed-magazine`);

    La URL /how-to-make-an-url-shorter, sin ningún parámetro de ruta, ahora mostrará la versión correcta de la página dependiendo de las cookies del usuario. El parámetro de ruta todavía "existe" en su aplicación, pero el usuario final no puede verlo y la URL permanece limpia. Perfecto.

    Resumen

    Para implementar la representación segmentada:

    1. Defina sus "segmentos" para una página.
      Ejemplo: usuarios pagos versus usuarios gratuitos, usuarios de la empresa A versus usuarios de la empresa B o C, etc.
    2. Representa tantas variaciones estáticas de una página como necesites, con una URL por segmento.
      Ejemplo: /with-jokes/my-article, /bland/my-article. Cada variación coincide con un segmento, por ejemplo, usuarios pagos o gratuitos.
    3. Configure un servidor de redireccionamiento muy pequeño, que verifique el contenido de la solicitud HTTP y redirija al usuario a la variación correcta, según su segmento.
      Ejemplo: los usuarios pagos son redirigidos a /with-jokes/my-article. Podemos saber si un usuario recibe pago o no al verificar las cookies de su solicitud.

    Implementación de renderizado segmentado. ( Vista previa grande )

    ¿Que sigue? ¡Aún más rendimiento!

    Ahora puedes tener tantas variaciones de la misma página como quieras. Resolvió su problema con los usuarios pagos de manera elegante. Mejor aún, implementó un nuevo patrón, Segmented Rendering, que brinda personalización al Jamstack sin sacrificar el rendimiento.

     

    Pregunta final: ¿qué pasa si tienes muchas combinaciones posibles? ¿Te gustan 5 parámetros con 10 valores cada uno? No se puede renderizar un número infinito de páginas en el momento de la compilación; eso llevaría demasiado tiempo. Y tal vez no tengas ningún usuario pago en Francia que haya elegido el tema ligero y pertenezca al segmento B para las pruebas A/B. Algunas variaciones ni siquiera valen la pena reproducirlas.

    Con suerte, los frameworks frontend modernos te ayudarán. Puede utilizar un patrón intermedio, como Regeneración estática incremental de Next o Generación estática diferida de Gatsby , para representar variaciones solo según demanda.

    La personalización de sitios web es un tema candente, lamentablemente contradictorio con el rendimiento y el consumo de energía. La representación segmentada resuelve este conflicto de manera elegante y le permite representar estáticamente cualquier contenido, ya sea público o personalizado para cada segmento de usuarios.

    Más recursos sobre este tema

    • “ Llevemos el Jamstack a SaaS: Presentamos Rainbow Rendering ”, Eric Burel
      Mi primer artículo que describe la arquitectura teórica genérica para Segmented Rendering (también conocido como “Rainbow Rendering”)
    • " Trate bien a sus usuarios con caché Http y renderizado segmentado ", Eric Burel
      Mi segundo artículo que muestra una implementación con middlewares Next.js
    • “ Renderiza cualquier cosa estáticamente con Next.js y Megaparam ”, Eric Burel
      Mi tercer artículo, Representación segmentada solo con caché HTTP (si usas Remix, te encantará
    • “ Generación estática incremental para múltiples rutas de renderizado ”, Eric Burel
      El ticket de GitHub en Next.js que lo inició todo.
    • “ Fundamentos teóricos para el renderizado estático y del lado del servidor ”, Eric Burel
      Mi borrador de artículo de investigación que describe las matemáticas detrás de SSR. Demuestra que el renderizado segmentado logra una cantidad óptima de renderizado en cualquier situación. ¡No puedes superar eso!
    • “ Personalización de alto rendimiento con Next.js Middleware ”, Raymond Cheng
      Un excelente caso de uso y demostración con Plasmic.
    • “ Pruebas A/B con Middleware Next.js ”, Raymond Cheng
      También de Plasmic, se está aplicando el renderizado segmentado a las pruebas A/B.
    • " Utilice Eleventy Edge para ofrecer sitios web dinámicos en el borde ", Blog de Eleventy Edge
      Eleventy Edge, una integración profunda entre 11ty y Netlify Edge Handlers para lograr la personalización.
    • “ Vercel/Platforms ”, Steven Tey
      Vercel Platforms, un ejemplo de renderizado segmentado para multiinquilino.
    • “ Evite cascadas de consultas en cargadores de Remix ”, Sergio Xalambrí
      Cómo paralelizar adecuadamente sus solicitudes de recuperación de datos (en el ejemplo de Remix).

    Lecturas adicionales sobre la revista Smashing

    • “ Patrones de renderizado de Jamstack: la evolución ”, Ekene Eze
    • “ Gestión del Estado en Next.js ”, Átila Fassina
    • " Jamstack CMS: el pasado, el presente y el futuro ", Mike Neumegen
    • “ Una guía completa para la regeneración estática incremental (ISR) con Next.js ”, Lee Robinson

    (NL, IL)Explora más en

    • Actuación
    • javascript
    • pila de mermelada
    • Siguiente.js





    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

    Un nuevo patrón para Jamstack: renderizado segmentado

    Un nuevo patrón para Jamstack: renderizado segmentado

    Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX Anuncie en la revista Smashing Índice

    programar

    es

    https://aprendeprogramando.es/static/images/programar-un-nuevo-patron-para-jamstack-renderizado-segmentado-1150-0.jpg

    2024-04-04

     

    Un nuevo patrón para Jamstack: renderizado segmentado
    Un nuevo patrón para Jamstack: renderizado segmentado

    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