Trata bien a tus usuarios con Renderizado Segmentado

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.

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.

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

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.

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

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