Si crees que el renderizado estático se limita a contenido genérico y público que es el mismo para todos los usuarios de tu sitio web, esta charla es para ti. El Renderizado Segmentado es un nuevo patrón para Jamstack que te permite personalizar contenido de forma estática, sin ningún tipo de renderizado del lado del cliente o renderizado del lado del servidor por solicitud. Obtén el mejor rendimiento posible para casos de uso como tematización, internacionalización, pruebas A/B, multiinquilinato y comienza a tratar bien a tus usuarios.
Video Summary and Transcription
La charla discute el concepto de renderizado segmentado para la personalización en el desarrollo web. Explora diferentes técnicas de renderizado, incluyendo el renderizado del lado del servidor, la generación estática de semillas y el renderizado dinámico. El problema de los invitados ricos y los clientes pobres se aborda a través del renderizado segmentado. La implementación del renderizado segmentado con Next.js involucra un servidor proxy ligero y la reescritura de URL. La charla también destaca los beneficios del renderizado invisible del lado del servidor y sugiere una futura API unificada para el renderizado del servidor.
Available in English
1. Introducción
Short description:
Hola a todos y bienvenidos a mi charla, Trata bien a tus usuarios con el renderizado segmentado. Mi nombre es Eric Burel. Soy el fundador de LBKE, una pequeña empresa en Montpellier, Francia. Soy un desarrollador web pero también un consultor en financiamiento público para investigación empresarial. Soy el mantenedor de VulcanJS, un framework que quizás conozcas si vienes del ecosistema de Meteor.js y que ahora se ejecuta en Next.js y GraphQL.
Hola a todos y bienvenidos a mi charla, Trata bien a tus usuarios con el renderizado segmentado.
Primero, permíteme presentarme. Mi nombre es Eric Burel. Soy el fundador de LBKE, una pequeña empresa en Montpellier, Francia. Soy un desarrollador web pero también un consultor en financiamiento público para investigación empresarial. Soy el mantenedor de VulcanJS, un framework que quizás conozcas si vienes del ecosistema de Meteor.js ecosistema y que ahora se ejecuta en Next.js y GraphQL. Soy miembro del Colectivo DevoGraphics creado por Sacha Gref, quien dirige las encuestas State of GS, CSS y GraphQL. Soy responsable en particular del formulario de encuesta donde realmente completas la encuesta y enseño Next.js en Human Coders, una empresa de enseñanza en Francia. Puedes encontrarme en Twitter o en Medium donde publico algunos artículos sobre varios temas, especialmente sobre Next.js y GraphQL.
2. Personalización y Renderizado
Short description:
Voy a hablar sobre personalización y explicar qué es el segmento en el renderizado segmentado. La personalización web incluye ejemplos como la tematización, la internacionalización, el contenido pago versus gratuito y las pruebas A-B. Next.js es un framework que ofrece tres formas de renderizar aplicaciones, incluido el renderizado del lado del cliente.
Voy a hablar sobre personalización para explicar qué es el segmento en el renderizado segmentado. Entonces, ¿qué es la personalización web? Tomemos un ejemplo. Elegir un tema es el ejemplo más básico y más visible de personalización web. Digamos que en mi aplicación tengo tres temas posibles: fuego, agua y hierba, y cada tema cambiará la apariencia de la aplicación. Para implementar la tematización, la mayoría de las veces usaré una cookie. Esto es muy común en la personalización web para almacenar información específica sobre el usuario en una cookie. ¿Por qué? Porque se envían automáticamente junto con cada solicitud y si no son solo HTTP, también están disponibles para el código javascript. Por lo tanto, son muy útiles para mantener información, para saber quién es el usuario. ¿Cuál es su segmento? ¿A qué categoría pertenecen, por ejemplo? Aquí podría tener una cookie llamada `starter` con tres valores posibles: fuego, agua y hierba. Y dependiendo del valor, por supuesto, elijo un tema diferente en la aplicación. Pero no es el único caso de uso. Hay muchos casos de uso de personalización web. Tenemos este mismo caso de uso, pero también la internacionalización. Es un caso de personalización que a veces olvidamos, pero cuando cambiamos el idioma de una aplicación para adaptarlo al idioma del usuario, estamos haciendo lo que llamamos personalización. Estamos optimizando el sitio web y la experiencia del usuario según sus características. El idioma que creemos que hablan o el idioma que seleccionaron en un menú. Esto es personalización. Tener contenido pago versus gratuito también es personalización, especialmente si solo tienes el comienzo de un artículo antes de llegar a un muro de pago. Esto es personalización en el sentido de que los usuarios no pagos tienen una experiencia diferente de los usuarios pagos. Los usuarios pagos tienen su contenido y se invita a los usuarios no pagos a suscribirse. Tienen una experiencia diferente, una experiencia personalizada, y pertenecen a diferentes segmentos: usuarios invitados y usuarios pagos. Las pruebas A-B también son un caso de uso muy importante, tal vez más avanzado, pero si obtienes mucho dinero de un sitio web, probablemente ya hayas configurado pruebas A-B porque te ayuda a probar nuevas versiones de tu sitio web de forma incremental sin afectar toda tu base de datos de usuarios. La mayoría de las veces tenemos dos segmentos que en realidad se llaman buckets en el entorno de pruebas A-B, A y B, y tienes dos versiones diferentes del sitio web A y B según este segmento.
Volvamos a nuestro caso de uso de renderizado de la cosa correcta. Hablemos de Next.js porque Next.js es un framework muy interesante cuando se trata de renderizar porque incorpora tres formas de renderizar aplicaciones. La primera es el renderizado del lado del cliente. Esta es la forma más común de renderizar contenido en aplicaciones modernas de JavaScript, en software como servicio, porque es muy dinámico. Ocurre en el navegador del usuario, por lo que puedes hacer muchos cálculos allí. Solo se utiliza JavaScript del lado del cliente y para obtener datos para llenar el contenido de la página, se utilizarán las funciones incorporadas del navegador, como Fetch, o bibliotecas que se basan en estas funciones incorporadas, como SWR en el ecosistema de Vercell.
3. Técnicas de Renderizado
Short description:
El renderizado del lado del servidor es lo opuesto al renderizado del lado del cliente. La generación de semillas estáticas es un punto intermedio que permite generar múltiples versiones de una página según los parámetros. El renderizado dinámico, como el renderizado del lado del cliente, permite actualizaciones en tiempo real pero requiere más cálculos. La generación estática, aunque no es adaptable a solicitudes individuales, es más rápida y puede ser tentadora para la personalización.
El renderizado del lado del servidor es lo opuesto. Se realiza todo en el servidor para cada solicitud. Esto se asemeja, por ejemplo, a cómo funciona PHP. Cuando haces una solicitud, se accede a una página que es una plantilla. En este punto, el servidor obtendrá algunos datos de la base de datos y llenará la plantilla con los valores correctos, y obtendrás tu página renderizada que se envía tal cual al navegador como HTML puro. Y tienes la generación de semillas estáticas, que se encuentra en el medio, que básicamente es solo renderizado del lado del servidor, pero no emparejado con la solicitud, sino calculado en el momento de la construcción. Es similar de alguna manera a simplemente escribir HTML. Podrías simplemente escribir la página. Pero, por supuesto, sería bastante tonto escribir el contenido directamente. Entonces, la generación de semillas estáticas te permite hacer esto a gran escala. Tienes la misma página y el generador de semillas estáticas puede generar múltiples versiones según algunos parámetros que ingreses, como el idioma, el tema, etc. Se dividen en dos categorías. La primera sería las formas dinámicas de renderizar contenido. El renderizado del lado del cliente y el renderizado del lado del servidor emparejado con la solicitud son dinámicos porque el renderizado del lado del servidor ocurre para cada solicitud. Por lo tanto, los datos pueden actualizarse cada vez que el usuario actualiza el navegador, al menos. El renderizado del lado del cliente es aún más dinámico porque puede ser interactivo, ya que opera en el navegador del usuario. Puede realizar cálculos en cualquier momento. Incluso ni siquiera tiene que comunicarse con el servidor. Entonces, la mayoría de las veces tienes este patrón, este patrón de llamadas a APIs para obtener nuevos datos y renderizar todo en el lado del cliente. Esta es una forma muy jam-stackish de hacer las cosas. La generación de semillas estáticas es, bueno, estática. Porque las cosas se calculan en el momento de la construcción, no pueden evolucionar para cada solicitud porque aún no tienes la solicitud. Nadie ha solicitado tu servidor, simplemente lo estás construyendo e implementando en este punto. Pero es más rápido porque las cosas ya están calculadas y almacenadas en una caché, por lo que no hay nuevos cálculos. El servidor solo tiene que servir el HTML calculado. Y ¿qué usarás para la personalización? Podrías estar tentado de decir patrones dinámicos porque pueden adaptarse a la solicitud porque pueden ocurrir en el navegador del usuario, literalmente en su máquina. Es más fácil adaptarse y personalizar para un usuario preciso, por supuesto. Sin embargo, son más lentos. Necesitan más cálculos. Entonces también tienes la opción de usar la generación estática, pero ¿cómo? Es más rápido, por lo que es
4. Renderizado Segmentado para Clientes Ricos
Short description:
El uso de renderizado dinámico y más lento para contenido personalizado crea un problema de clientes ricos y pobres. Los visitantes no pagados y los usuarios invitados reciben renders estáticos más rápidos, mientras que los clientes autenticados con contenido personalizado experimentan un renderizado más lento. El renderizado segmentado aborda este problema al permitir renders estáticos para contenido personalizado.
tentador. Pero ¿cómo? Nuevamente, dado que no se mueve, ¿cómo lo haces? Y el uso sistemático de la solución dinámica y más lenta conduce a un problema que llamo el problema de clientes ricos y pobres. Utilizarás los renders estáticos más rápidos solo para contenido público, para contenido que está disponible para cualquier persona que navegue por la web. Por lo tanto, visitantes no pagados, usuarios invitados, así como usuarios conectados. Y utilizarás los renders dinámicos más lentos para contenido personalizado. Utilizarás el tiempo de CPU de los usuarios si haces renderizado del lado del cliente. Tendrás una computación más lenta en el backend si haces solicitudes emparejadas con el renderizado del lado del servidor. Básicamente, tus clientes autenticados que reciben contenido personalizado basado en sus propios datos personales tienen el patrón más pobre, el patrón más lento. Ellos son clientes pobres, mientras que los invitados que a menudo proporcionan menos valor en el sitio web porque no están conectados, no los conoces, no puedes dirigirte a ellos, no son clientes, tienen la mejor experiencia. Son clientes ricos. Este es el problema de clientes ricos y pobres. Y el renderizado segmentado es una forma de reducir este problema al permitir renders estáticos para contenido personalizado y tener clientes ricos.
5. Personalización Estática y Servidor Proxy
Short description:
Hablemos sobre la personalización estática utilizando patrones de renderizado segmentado. La implementación más sencilla es tener una URL por segmento, una URL por elección de tema para los usuarios. Pero esto conlleva algunos problemas. Los usuarios no deberían poder saber en qué segmento se encuentran. La URL puede volverse larga y fea. Para resolver este problema, introduzcamos un servidor proxy simple y ligero.
Entonces hablemos sobre la personalización estática utilizando patrones de renderizado segmentado. Hagamos un primer intento, intentemos utilizar la URL para personalizar el contenido de forma estática. Es muy fácil porque la mayoría de los generadores de semillas estáticas se basan en la URL, ya sea Next.js, Gatsby, Astro, y así sucesivamente. Les proporcionas URLs para renderizar y, dependiendo del parámetro, buscarán los datos correctos y renderizarán la página en consecuencia. Así es como funcionan. Por lo tanto, la implementación más sencilla es tener una URL por segmento, una URL por elección de tema para los usuarios. Entonces los usuarios que eligieron el tema de fuego tendrán una versión, los que eligieron el tema de agua tendrán otra versión, y los que eligieron el tema de hierba tendrán otra versión. Pero esto conlleva algunos problemas. Primero, el usuario puede cambiar la URL. Está bien para un tema, está bien para un idioma. Incluso es una característica en cierto sentido para un idioma. Puedes cambiar el idioma de la página simplemente cambiando la URL. Pero es un problema si comienzas a hacer personalización con contenido de pago. No quieres que los usuarios cambien la URL para convertirse repentinamente en usuarios de pago. Preferirías que paguen por algo. Luego, el usuario puede ver el parámetro. Nuevamente, no es un problema para un idioma, incluso es algo bueno para un idioma porque permite compartir la URL con otras personas que hablan el mismo idioma y así obtienen el contenido correcto. Pero para una prueba A-B, eso es un gran problema. Los usuarios no deberían poder saber en qué segmento se encuentran. De lo contrario, estarías sesgando drásticamente la prueba A-B. Esto conlleva muchos problemas y los datos simplemente ya no son válidos. Por lo tanto, no deberían ver el parámetro en este caso. Y finalmente, la URL puede volverse larga y fea. Si tienes muchos parámetros, terminarás con el idioma, el tema oscuro o claro, el inquilino, la empresa, la organización a la que pertenecen los usuarios. Si estás haciendo negocios a nivel empresarial, es muy común tener multiarrendamiento. Tener múltiples empresas que utilizan tu aplicación con muchos usuarios por empresa. Tendrás el segmento de prueba A-B, que no es bueno, contenido de pago, y así sucesivamente. Tendrás URLs muy largas y feas. Entonces, para resolver este problema, esta limitación, introduzcamos una nueva pieza en nuestra arquitectura. Introduzcamos un servidor proxy simple y ligero.
6. Servidor Proxy y Reescritura de URL
Short description:
El servidor proxy reescribe la URL en función del segmento, haciéndola invisible para el usuario y protegiéndola de ser modificada. La longitud y apariencia de la URL ya no son un problema, y existen patrones avanzados para comprimir parámetros si es necesario.
El papel de este servidor proxy será tomar la solicitud HTTP que llega al servidor y reescribir la URL, dependiendo del segmento. Insisto en la palabra reescribir la URL, y no redirigir la URL. Una reescritura de URL no es visible para el usuario final, y esa es la diferencia clave, porque resuelve todos nuestros problemas con la URL de una vez. El usuario ya no puede ver el parámetro. El usuario ya no puede cambiar el parámetro, porque está protegido por el servidor, se calcula en el lado del servidor. Por lo tanto, el usuario no puede manipularlo simplemente cambiando los valores del navegador. Y finalmente, el hecho de que la URL sea larga y fea ya no es un problema, porque los usuarios ya no la ven. Puedes alcanzar la limitación de 255 caracteres para la URL, pero en la práctica esto nunca sucederá realmente. Y aún así tenemos más, incluso más patrones avanzados para solucionar eso. Está vinculado en el recurso y se llama Megaparam patrones. Básicamente, puedes codificar los parámetros para comprimirlos. Así que hay una solución incluso para este ligero
7. Renderizado Segmentado y Reescritura de URL
Short description:
Para resolver nuestro problema, convertimos la cookie en un parámetro de URL compatible con los frameworks existentes. Esto se llama renderizado segmentado, donde cada variación tiene una URL única. Por ejemplo, para la internacionalización, se puede utilizar el encabezado de aceptación de idioma para reescribir la URL al idioma correcto, eliminando la necesidad de un parámetro de idioma explícito. Los usuarios pueden cambiar el idioma utilizando una cookie invisible en lugar de un parámetro de URL visible.
limitación. Entonces, para resolver nuestro problema, tenemos una solicitud HTTP con la cookie fire y convertimos eso en un parámetro de URL fire, que es compatible con la forma en que funcionan los frameworks existentes porque Gatsby, NEFGS podrán renderizar contenido estáticamente siempre que la URL para cada variación sea única. Esto es lo que llamamos renderizado segmentado. Esta es una receta con dos ingredientes teniendo una URL por segmento. Así es como funciona el renderizado estático. Si genera múltiples variaciones de su sitio web estáticamente, ya está haciendo esto, pero el truco es usar un pequeño servidor de reescritura de URL para redirigir a la URL correcta según otros parámetros de la solicitud como las cookies o los encabezados. Si tomo otro ejemplo con internacionalización, podría usar el encabezado de aceptación de idioma y reescribir la URL al idioma correcto. Esto eliminaría la necesidad de tener un parámetro de idioma explícito. Aún necesita una forma para que los usuarios cambien el idioma, pero podría hacerlo utilizando una cookie que sea invisible en lugar de usar un parámetro de URL que sea visible y en algunos escenarios podría ser feo.
8. Implementación con Next.js
Short description:
Veamos una implementación con Next.js. Nuestra aplicación utiliza el renderizado segmentado para permitir a los usuarios elegir un tema. El tema se almacena en una cookie, lo que proporciona personalización sin alterar la URL. La página se renderiza estáticamente con el tema elegido y la respuesta del servidor confirma el tema correcto. La implementación involucra la generación estática de semillas y la regeneración estática incremental para mayor flexibilidad. El middleware, un servidor proxy ligero, lee la cookie del tema y escribe la URL. Esto logra el renderizado segmentado sin necesidad de un parámetro raíz.
Ok, esto puede sonar un poco abstracto. Ahora veamos una implementación con Next.js que es muy interesante porque permite que Next.js incorpore el concepto de middlewares de borde que son exactamente eso. El servidor proxy que necesitamos para implementar el renderizado segmentado. Ellos lo proporcionan de forma nativa. Así que aquí está nuestra aplicación utilizando el renderizado segmentado. Es una aplicación de Next.js que me permite elegir un tema: fuego, agua o hierba. Ok, elijamos el tema de fuego. Verás que cambia el color como se esperaba. La parte interesante es que no altera la URL. Primero, si voy a la aplicación y reviso las cookies, veré que estoy utilizando la cookie de tema llamada 'fire' en lugar de usar un parámetro raíz. Estoy utilizando una cookie, que es la forma correcta de hacer personalización en muchos escenarios. El segundo hecho interesante es que si recargo la página, obtendré la versión temática de inmediato. Por supuesto, todo esto se renderiza estáticamente, así que por ejemplo, si voy a la red y reviso la respuesta del servidor para la solicitud html, veré mi contenido con el tema correcto. Aquí no he configurado el CSS para el renderizado en el servidor, pero puedo ver el tema de fuego en el html. Así que estoy utilizando el renderizado estático. Esto se calcula en el lado del servidor avanzado, no hay cálculos en el lado del cliente.
En cuanto a la implementación, la primera parte es simplemente una página con generación estática de semillas como encontrarías en cualquier aplicación de Next.js utilizando 'getStaticPaths' y 'getStaticProps' como de costumbre. Genero diferentes versiones de la página dependiendo del parámetro de tema. Observa que estoy utilizando la regeneración estática incremental, que es solo un patrón en Next para entender cómo manejar el caso en el que tengo muchos temas. Por ejemplo, aquí no estoy pre-renderizando el tema verde porque tal vez es menos solicitado por las personas y no quiero tener un tiempo de compilación muy largo, por lo que solo se calculará en la primera solicitud. Tenemos mucha flexibilidad con este enfoque. Y luego, por supuesto, renderizo mi página en función de este parámetro. Esto es muy común si usas Next.js o cualquier otro framework de renderizado estático, estarás acostumbrado a este enfoque. Pero la parte más importante es el middleware. Este es mi servidor proxy. Y cuando digo pequeño y ligero, no estoy bromeando. Son 25 líneas con muchos comandos. Lo que hace es leer las cookies. Si es un tema válido, escribirá la URL. Así de simple. Así es como obtengo el renderizado segmentado, renderizado estático con personalización sin
9. Renderizado en el servidor invisible y el futuro
Short description:
Esta parte discute la seguridad y los beneficios del renderizado en el servidor invisible para temas personalizados. También menciona el ejemplo de implementación y el uso del renderizado segmentado en el borde. La conclusión destaca la importancia del almacenamiento en caché en el renderizado en el servidor y sugiere una API unificada futura para el renderizado en el servidor.
El uso de un parámetro raíz. Esto es invisible para el usuario y es seguro porque ocurre en el lado del servidor. No puedo permitir que el usuario elija un tema que no existe, por ejemplo. Solo pueden seleccionar fuego, agua, hierba o ninguno. De lo contrario, lanzo un error. Esto es seguro. Es excelente para contenido de pago, por ejemplo, pruebas A-B. Finalmente, solo un detalle, pero eso es opcional, he agregado cierta lógica para cambiar el tema basado en una cookie utilizando una raíz de API. Entonces, estoy utilizando el encabezado HTTP de configuración de cookie, pero podrías hacer lo mismo en el lado del cliente, por supuesto. Volvamos a mis diapositivas. Ahora tienes un ejemplo de implementación, y en Vercel, es posible que haya una terminología diferente. No lo llamarán renderizado segmentado. Lo llamarán personalización en el borde. Y en realidad, es la traducción de Vercel de este patrón. Es lo mismo, excepto que Vercel te permite tener renderizado segmentado en el borde utilizando su red de borde. Pero es básicamente la misma idea. Breve conclusión. ¿Cuál es el futuro del renderizado en el servidor? Creo que el futuro del renderizado en el servidor es comprender que todo se trata del almacenamiento en caché. Lo estático es el renderizado en el servidor almacenado en caché en el momento de la compilación. El renderizado en el servidor por solicitud es simplemente una falta de caché en el mismo patrón. La clave de caché no es solo la URL, sino la solicitud completa. Esta es la idea detrás del renderizado segmentado, utilizar la solicitud y no solo la URL. Y el valor es, por supuesto, el HTML renderizado o los datos. Depende del patrón. El renderizado estático diferido de Gatsby, por ejemplo, desvincula ambos y Next.js siempre los considera como un todo. Están muy relacionados en Next, pero de cualquier manera, ese es el valor de caché. Entonces, mi opinión es que en el futuro, tendremos una API unificada para el renderizado en el servidor que abarque el renderizado estático, por solicitud y todo lo que haya en el medio. Y hasta entonces, tenemos el renderizado segmentado. Gracias por su atención y nos vemos más tarde.
