Querido cliente, te estoy dejando

Hola. Hola a todos. Gracias por asistir a mi charla. Soy Liad Yosef. Mi charla se llama Querido Cliente, Te Dejo. Vamos a hablar un poco sobre la renderización del lado del servidor, la renderización del lado del servidor, y todo lo que hay en medio. Así que soy Liad Yosef. Soy el arquitecto principal de front-end en Douda. Soy un entusiasta de la web y en mi tiempo libre también soy un astronauta analógico. Tengo el privilegio de participar en misiones analógicas en todo el mundo, me gusta mucho el espacio. Así que con esto en mente, convertiremos nuestra charla en algo así como una charla en modo oscuro, y será temática espacial. Entonces podrías preguntarte, ¿por qué necesitamos hablar sobre la renderización del lado del servidor? Abraham Lincoln dijo una vez que si tuviera ocho horas para cortar un árbol, pasaría seis afilando mi hacha, y Rick Sanchez agregó que el universo es mucho más complicado de lo que piensas. Así que prepárate para una aventura de 20 minutos en la madriguera del conejo de la renderización del lado del servidor, ¿y cómo lo abordamos en React? Así que es hora de maratón, y todos sabemos que preferimos ver Netflix en lugar de ver

Hay una charla muy buena de Rich Harris llamada, Las aplicaciones de una sola página arruinaron la web, y en general hay una muy buena charla en la esfera de Twitter o en la web sobre aplicaciones de una sola página versus aplicaciones de varias páginas, donde algunas personas dicen que las aplicaciones de varias páginas no cumplen con las expectativas que queremos y otras personas dicen que las aplicaciones de una sola página, debido a su carga lenta, no ofrecen el rendimiento que queremos. Ese es un debate en curso.

Pero para entender un poco de qué estamos hablando, necesitamos entender qué estamos hablando cuando hablamos de renderización. Así que, renderización 101, hablamos de quién construye el marcado. Puede ser el cliente, el servidor o el borde en el medio. ¿Cómo se vuelve interactivo? ¿Es el cliente el que lo hace interactivo? ¿O es el código JavaScript el que lo hace interactivo? ¿Son las funciones nativas del navegador? ¿O es React el que lo hace interactivo? ¿Cuándo se construye? ¿Se construye en tiempo de compilación o en tiempo de ejecución? Y, por supuesto, ¿desde dónde se sirve? ¿Se sirve desde algún tipo de red de borde, una caché o el propio servidor?

Entonces, si pensamos en un blog simple, por ejemplo, que es muy estático, entonces sabemos que se construye en tiempo de compilación, es interactivo. Estamos usando código JavaScript. El servidor lo está construyendo y se sirve desde la caché, ¿verdad? Porque no necesitas reconstruirlo en tiempo de ejecución. Pero si tienes una aplicación web compleja, eso es algo que el cliente está construyendo, probablemente usando React u otros frameworks, y requiere un servidor. Requiere un servidor en tiempo de ejecución para funcionar.

Entonces, si pensamos en esas dos partes, esos dos bordes, tienes la renderización del lado del servidor para páginas muy estáticas y simples, por un lado, y tienes la renderización del lado del cliente para aplicaciones web muy complejas, por otro lado, puedes colocarlos en un espectro, porque esas no son las únicas dos opciones que tenemos. Entonces, en la renderización estática, que es la renderización del lado del servidor en tiempo de compilación, obtienes la misma página para todos y se puede almacenar en caché fácilmente, pero no se puede personalizar. Y no puedes tener variantes, porque necesitas construir todo en tiempo de compilación y requiere una compilación para cada actualización, mientras que en la aplicación del lado del cliente, que es la más dinámica, se puede personalizar fácilmente porque se hace bajo demanda en la solicitud, pero no se puede almacenar en caché y tiene una carga inicial lenta y una obtención de datos lenta, porque tienes que ir al servidor para todo, pero tiene una capacidad de respuesta rápida en la aplicación. Pero debemos recordar, esto es un espectro, así que si quiero construir una página de listado y quiero que cada página en el listado sea diferente, porque tengo 10,000 propiedades que quiero listar, entonces puedo usar algo que se llama regeneración estática incremental, que no solo genera todo en tiempo de compilación, sino que genera algunos de ellos en tiempo de compilación y otros bajo demanda. Si quiero construir algo más personal, como mis reservas o mi cuenta, o cosas que necesitan mis datos, necesitan mis cookies para presentarse, entonces tendría que ir con la renderización en tiempo real del lado del servidor, porque no puedo almacenar en caché nada, y, por otro lado, si quiero construir una aplicación web, pero la mayoría de las partes de la aplicación web son estáticas y solo algunas partes son dinámicas, iría con componentes de nivel React. Hablaremos de todas estas estrategias. Entonces, cuando hablamos de estrategias SSL o el multiverso de la locura, debemos recordar que cuando hablamos de renderización estática, ya no hablamos solo del cliente y el servidor. Necesitamos poner algo en el medio, que es la red de borde o la caché, y luego podemos discutir sobre las relaciones entre el cliente, el borde y el servidor. En la renderización estática clásica, que es como vimos, las páginas de blog, el servidor genera la página en tiempo de compilación y envía la página a la caché, a la red de borde, y luego sale de la imagen. Ya no necesitamos el servidor. Simplemente generó la página y ya está. El cliente solicita la página a la caché o al borde y obtiene la página, obtiene la publicación del blog, y es importante entender. Es importante tener en cuenta que todos los clientes obtendrán la misma página porque todos la solicitan desde la caché. Como dijimos, las páginas se pueden almacenar en caché fácilmente y no requieren un servidor, y tienen un gran rendimiento, pero necesitan reconstruirse para cada actualización, y hay un problema con la obtención de datos. En la regeneración estática incremental, el servidor construye la página, la envía a la caché para que se almacene en caché, pero también construye muchas variaciones, muchas otras variaciones en la caché, y cuando el cliente solicita la página a la caché, obtienen la página, y otro cliente puede solicitar otra página y obtendrá otra página, pero si un tercer cliente solicita una página que no existe en la caché o en la red de borde, entonces va directamente al servidor. El servidor lo genera en tiempo real y lo envía a la caché, lo almacena en caché, y luego el cliente se comunica con la caché y obtiene esta página. Es como lo mejor de ambos mundos, pero aún necesitas un servidor. También puede ser activado por la caché. Puedes establecer un tiempo de invalidación. Por ejemplo, si tienes una página que necesita ser validada o actualizada cada par de minutos, cuando el cliente solicita la página a la caché, la caché puede decir que esta es la página que quieres, y el siguiente cliente, la caché puede decir, oye, la página está obsoleta, pidiendo al servidor que la regenere, mientras al mismo tiempo sirve la página obsoleta al cliente, y luego el servidor regenera una nueva página, la reemplaza en la caché, y luego el siguiente cliente obtendrá la página actualizada.

La renderización estática incremental permite el almacenamiento en caché y reduce los tiempos de compilación para múltiples páginas, pero no puede reflejar datos específicos del usuario. Entonces, si tienes miles de publicaciones de blog, no tienes que construir todas ellas de antemano, pero requiere un servidor y no puede reflejar datos específicos del usuario porque no vas realmente al servidor y generas una página única, y los viajes al servidor son largos.

La renderización completa en el servidor, eso es lo que llamamos renderizado en el lado del servidor, tenemos que recordar que la caché ya no está en la ecuación, el cliente se comunica directamente con el servidor, por lo que el cliente puede solicitar una página altamente personalizada, por ejemplo, detalles de la cuenta, mis listados o mi cuenta, y el servidor la construirá y la enviará al cliente algo muy único para ese cliente. Y si otro cliente solicita la página al servidor, el servidor construirá algo completamente diferente, porque es un cliente diferente, un cliente diferente, y se lo enviará.

Entonces, en la renderización completa en el servidor, obtenemos un contenido altamente personalizado y páginas únicas, y no necesitamos un proceso de compilación, lo cual es importante, pero requiere un servidor y aún tenemos el largo tiempo de respuesta desde el servidor. ¿Por qué el largo tiempo de respuesta? Porque si miramos el código del servidor, por ejemplo, podemos ver que la línea relevante aquí es una renderización a cadena, y esta línea es síncrona, por lo que necesitamos renderizar todo antes de poder enviar la página, y eso es un problema. Y discutiremos algunas formas de resolverlo pronto.

Y hay voces que dicen que si tu renderizado en el lado del servidor tarda más de 200 milisegundos, tal vez sea mejor hacer el renderizado en el lado del cliente en su lugar.

Y ahora lo nuevo de lo que todos están hablando es el renderizado en el borde o el uso de la red de borde para renderizar, y eso es como tener lo mejor de ambos mundos, porque si tenemos la red de borde que se está extendiendo por todo el mundo, podemos usarla para renderizar las páginas. No tenemos que hacer viajes al servidor. Entonces, si simplemente unimos el renderizado y la red de borde, podemos tener algo como esto. Podemos tener la red de borde alrededor del mundo, el cliente solicita una página similar a una persona desde la red de borde. La red de borde la construye y la devuelve en tiempo real. Pero como la red de borde es como una CDN, se extiende por todo el mundo, obtienes el punto de borde que está más cerca del cliente, lo que lo hace rápido. Entonces, el renderizado en el borde permitirá la transmisión, porque ahora que tienes tiempos rápidos y cortos entre el borde y el cliente, puedes transmitir HTML al cliente para que el cliente pueda ver partes del HTML mientras se están renderizando. Requiere una red de borde y Next lo admite, Remix lo admitirá, Netlify tiene Netlify Edge Functions, que es bastante impresionante. Eso es algo que debes tener en cuenta.

Y ahora hablemos de nuestro némesis, nuestro enemigo, la hidratación. Entonces, la hidratación es en realidad el proceso que ocurre en el cliente después de recibir el marcado. Y eso es un problema, porque si lo piensas, ¿quién le da vida al marcado? Puede ser el navegador que utiliza interacciones nativas del navegador como envío de formularios y menús desplegables y cosas que el navegador sabe cómo manejar. Remix se basa mucho en esto. O puede ser JavaScript, ¿verdad? Entonces, el navegador puede pedir al servidor que envíe algún código JavaScript para hacer que el marcado cobre vida o sea interactivo. O puede ser React. Pero React hace la hidratación, lo que significa que construye todo el marcado en el servidor y luego el servidor lo envía al cliente y luego el cliente tiene que pedir a React nuevamente para reconstruir el marcado, lo cual es bastante ineficiente, reconstruir el marcado. Y solo entonces agrega la lógica de interacción, ¿verdad? Esta es una hidratación basada en React y en React, necesitamos enviar al cliente tanto el código de renderizado como el código de interacción, lo que hace preguntarse si el único código que necesitamos es este es el código de interacción. ¿Por qué necesitamos enviar todo esto al cliente? Entonces, la hidratación se está convirtiendo en un problema porque tienes que enviar todo el código al cliente y porque no puedes hidratar parcialmente. Tienes que esperar a que todo el código llegue al cliente hasta que puedas hidratar. Puedes leer a Steve Sower, tiene una publicación de blog muy buena al respecto. Y React está tratando de resolverlo con suspense como inicio y otros componentes de React.

Entonces, una breve introducción sobre suspense. Si queremos renderizar algo de forma perezosa, como aquí, queremos renderizar el ratón solo si Elon Musk está presente. Lo envolvemos en suspense y luego obtenemos un bonito spinner si queremos. Y solo cuando Elon Musk llega, podemos renderizar el ratón. Así es la idea de suspense.

Nuestro problema con SSR, como dijimos, es que necesitamos obtener todos los datos de antemano en el servidor, cargar todo el JavaScript antes de la hidratación y luego hidratar todo antes de poder interactuar con él. Es como una cascada. El servidor obtiene todos los datos, luego el servidor renderiza todo el HTML y lo envía al cliente. Luego, el cliente carga todo el código JavaScript y luego necesita hidratar toda la aplicación. Eso es un problema.

Entonces, si queremos construir un sitio web de mentoría para los Avengers y lo llamamos mentor, por ejemplo, todos pueden seleccionar un mentor de su elección, y tienes la página del mentor, que tiene la imagen y las reseñas del mentor y el nombre del mentor, ¿verdad? Lo construimos en React. Es bastante simple. Tenemos el nombre, la imagen, la descripción y las reseñas. Y digamos que quieres, si el servidor lo renderiza, es muy simple. El servidor simplemente lo renderiza en el marcado, lo envía al cliente y luego React hace su magia en el cliente y se vuelve interactivo y eso es increíble. Pero digamos que quieres que la imagen del mentor y las reseñas del mentor se carguen de forma perezosa. Tal vez lleva mucho tiempo obtener las reseñas de la fuente de datos de terceros. Entonces quieres envolverlo, digamos, en suspense, ¿verdad? Lo envolverías en suspense con un fallback. Pero luego tienes un problema con el SSL, porque React lo renderizará en el servidor, pero no sabe qué hacer con la parte de suspense. No lo sabe, porque no está ahí, así que lo enviará al cliente, pero React en el cliente realmente no sabe qué hacer. Eso es un problema, porque tienes que obtener todo de antemano. Y esta es la parte donde SSL se vuelve difícil. Por eso no utilizamos realmente SSL a gran escala hasta hace unos años, porque es difícil. Pero SuspenseSSL viene a nuestro rescate en React 18. React introdujo el streaming de HTML, la capacidad de transmitir HTML al cliente, y SelectiveHydration, la capacidad de hidratar selectivamente partes de los clientes. Entonces, en lugar de usar renderToString en el servidor y hidratar en el cliente, simplemente podemos hacer renderToPipe del stream y hidratar la raíz en el cliente. Y luego el mismo código de suspense se renderizará en el servidor con la carga y el spinner y se enviará al cliente. Luego, React hidratará todo lo que pueda en el cliente. Y solo cuando las reseñas estén listas, el servidor enviará al cliente algún tipo de script que diga, `oye, las reseñas están listas. Solo reemplázalas en el marcado`, lo cual es bastante sorprendente.

Y también sabe cómo hacer SelectiveHydration. Si varias partes de la página se están hidratando y el usuario hace clic en una de ellas, entonces React prioriza automáticamente esta parte para ser hidratada y sabe cómo reproducir los clics en esta parte, lo cual es genial. React Server Component también es un cambio de juego. Básicamente significa que si tienes una página en la que la mayor parte está renderizada estáticamente, no necesitas mucho código de interacción, no necesitas React, pero quieres renderizarlo con React. Por ejemplo, solo la calificación del mentor es algo que quieres que sea interactivo. Entonces puedes definir algunas partes de la página como componentes del servidor, y esas partes pueden acceder a la base de datos y agrupar muchas dependencias, pero ninguna de ellas se enviará al cliente. Entonces, si solo defines partes como componentes del servidor y solo tu parte interactiva la defines como componente del cliente, solo este componente del cliente se agrupará y se enviará al navegador, lo que puede reducir el paquete en un 90%, lo cual es asombroso. Hay una buena charla de Dana Bramov al respecto, te recomiendo leer el RFC de componentes del servidor, es muy informativo. No podemos hablar de SSR sin mencionar a Next.js. Next.js se está convirtiendo en la solución de facto para el renderizado SSR de React. Permite tanto la generación de sitios estáticos, por lo que puedes utilizar getStaticProps y luego definir que esta página se renderizará en el momento de la construcción, como el renderizado en el lado del servidor con getServerSideProps y luego el servidor lo renderizará, lo cual es asombroso. Acaba de recibir una actualización para diseños o rutas anidadas, lo que te permite transmitir partes de la página al cliente. Eso va a ser realmente importante. No se puede hablar de Next sin mencionar a Remix, que es el nuevo niño en la ciudad. También es bastante impresionante. Va en una dirección diferente al no enviar mucho JavaScript al cliente, sino confiar en los navegadores nativos para trabajar con la página. También tienen rutas anidadas. De hecho, ya tenían enrutamiento anidado antes. No utilizan los componentes del servidor de React, en realidad tenían una demostración que muestra que son más rápidos que los componentes del servidor de React, lo cual es asombroso. Remix y Next se están convirtiendo en la próxima guerra o debate. Puedes leer muchos tweets al respecto. Algunos dicen que Next es mejor, otros dicen que Remix es mejor, porque se siente como PHP para React. No sé si es un cumplido o no, pero lo es. Es importante recordar que eventualmente necesitas elegir las herramientas correctas para el trabajo y eventualmente convergerá en algo. Lo más importante es recordar que el renderizado en el lado del cliente sigue siendo bastante bueno. No tienes que usar el renderizado en el lado del servidor todo el tiempo, aún puedes hacer renderizado en el lado del cliente. Cliente y servidor no tienen que ser enemigos, podemos trabajar juntos. Si todo esto es demasiado y abrumador y estás diciendo, hey, no puedo entender todo esto, simplemente puedes volver a tu Netflix y elegir un episodio familiar y reconfortante de Hooks, y leer un poco más sobre Hooks. Recuerda, el futuro es increíble, y tú eres increíble, muchas gracias.