Out-of-Order Streaming – El Futuro del Desarrollo Web

Hablemos sobre el rendimiento y más específicamente sobre el rendimiento web. Y siempre que hablamos de rendimiento web, especialmente en estos días, la conversación generalmente muy rápidamente se desvía hacia cosas como el renderizado del lado del servidor y tal vez incluso el streaming como una forma de hacer que tu renderizado sea lo más rápido y eficiente posible. Ahora, en esta charla, quiero explorar cómo se ve ese panorama del renderizado web en este momento, cómo llegamos allí, algunas de las limitaciones del renderizado tradicional del lado del servidor y el streaming, y luego profundizar específicamente en cómo el streaming fuera de orden resuelve algunas de esas limitaciones para que, con suerte, al final de esto, no solo tengas una idea de qué es el streaming fuera de orden y cómo funciona, sino que quizás más importante, con suerte tendrás una idea de qué problemas realmente resuelve y cuál es la motivación principal detrás de esta tecnología.

Un breve descargo de responsabilidad antes de comenzar. Esta no va a ser una charla en la que te voy a decir que tienes que usar el renderizado del lado del servidor y el streaming fuera de orden, y de lo contrario eres estúpido y estás equivocado. Solo quiero dar algunos detalles sobre cómo funciona y por qué podría ser útil para que puedas irte y tomar una decisión, con suerte, más informada por ti mismo basada en tus proyectos y tu equipo y todos los demás requisitos, cualquiera que sea la mejor solución para ti.

Con eso fuera del camino, comencemos con el porqué. ¿Qué problemas realmente resuelve el streaming fuera de orden? Y para entender eso, necesitamos echar un vistazo rápido a la historia del renderizado web y cómo llegamos a donde estamos hoy. Y tenemos que comenzar desde el principio, lo que yo llamaría los buenos viejos tiempos, con HTML simple y tal vez algún lenguaje del lado del servidor además de eso. Estoy usando PHP aquí, principalmente porque eso es lo que usé cuando comencé. Realmente no importa. Podría ser cualquier otro lenguaje del lado del servidor. Fundamentalmente, todos hacen lo mismo, que es generar ese HTML sobre la marcha.

Entonces, si visualizamos eso, tenemos un navegador que hace una solicitud al servidor para una página específica. Ese servidor luego genera HTML, devuelve ese HTML y el navegador lo renderiza. Y eso es todo. Tiempos mucho más simples, porque ese HTML es puramente estático. Aún no tenemos elementos dinámicos. El tiempo de respuesta del servidor realmente depende de lo que estamos haciendo en el servidor. Así que si solo estamos buscando archivos HTML estáticos, eso es realmente rápido. Cuanto más hacemos en el servidor, digamos que nos conectamos a una base de datos, o estamos obteniendo datos de APIs de terceros, cuanto más hacemos, más lento se vuelve el tiempo de respuesta. Y eso es molesto en la carga inicial, porque estás esperando que ese HTML llegue durante mucho tiempo. Pero se vuelve aún más molesto a medida que navegas por la página, porque cada vez que haces clic en un enlace, tenemos que hacer todo ese ciclo completo nuevamente. Volvemos al servidor, el servidor genera todo el HTML para la nueva página, lo devuelve y luego lo renderiza. Así que esto es realmente frustrante para las páginas donde hacemos más en el servidor. Así que intentamos resolver ese problema introduciendo JavaScript. Específicamente, esta es una especie de era de jQuery y la introducción de tecnologías como AJAX. Así que estamos hablando de alrededor de 2006 aquí. Y la idea era que con JavaScript, A, podemos hacer que nuestras aplicaciones sean más interactivas y dinámicas. Así que ahora, cuando estamos solicitando una página, todavía estamos volviendo al servidor, el servidor todavía devuelve HTML estático, pero ahora el servidor también puede devolver un archivo JavaScript.

Y luego el navegador analiza y ejecuta el archivo JavaScript, y ese JavaScript podría inyectar algunos event listeners o click handlers en botones y cosas. O algún estado local, y hacer que tu aplicación sea más dinámica. Ahora, esto es genial para la experiencia general del usuario. Pero para resolver ese largo tiempo de espera cuando navegas, la introducción de AJAX realmente ayuda. AJAX nos permitió hacer solicitudes de red desde el cliente incluso después de que la carga inicial de la página ya haya terminado. Lo que significa que cuando navegamos a una nueva página, digamos que tenemos muchos elementos estáticos como una navegación y elementos de diseño que son todos iguales en todas las páginas. Podemos ser mucho más específicos sobre lo que realmente estamos solicitando del servidor. Y solo solicitar como un subconjunto del HTML. Lo que significa que el tiempo de respuesta del servidor generalmente es mucho más rápido, pero también significa que todo esto sucede en el cliente. Así que tenemos el control total sobre cualquier tipo de estados de carga que queramos mostrar mientras el usuario espera que llegue ese contenido. Lo que mejora enormemente la experiencia del usuario en esas necesidades de navegación.

Ahora, una vez que introducimos JavaScript en el buen estilo de JavaScript, nos volvemos un poco adictos y rápidamente nos lanzamos de lleno a eso. Y entramos en la siguiente fase que es algo así como la era de las aplicaciones de una sola página. Así que solo plain jQuery. Luego rápidamente construimos frameworks de aplicaciones que nos ayudaron a construir la forma de aplicaciones normales con cosas como Knockout.js. Y luego comienzas a ver los frameworks que todavía conocemos, amamos y usamos como React, como Vue, como Angular. Y la idea es que eliminamos completamente el servidor. Así que ahora cuando solicitamos una página, todo lo que realmente hace el servidor es devolver un contenedor vacío con los documentos compartidos, como un div vacío. Y un archivo JavaScript. Y la idea es que ese JavaScript construirá todo el HTML dinámicamente en el cliente y lo inyectará en ese div vacío. Así que una vez que el JavaScript está completamente descargado, analizado y ejecutado, obtenemos nuestra aplicación y es inmediatamente interactiva. Y todo es interactivo porque todo está construido en JavaScript. Así que ya no hay barreras para agregar event listeners, y estado local, y todo eso en ese momento. Lo cual es genial para la experiencia del usuario.

Así que aquí es donde la construcción de aplicaciones mucho más mejoradas y experiencias de usuario mucho más grandes explotó porque era mucho más fácil construirlas a gran escala. Y navegar porque todo sucede en el cliente suele ser bastante rápido. Solo está limitado por, ¿necesitamos hacer algunas solicitudes de red para obtener nuevos datos para la nueva página, o ese tipo de cosas? Pero solo renderizar nuevo HTML para una nueva página suele ser razonablemente rápido. La verdadera desventaja aquí es esa carga inicial, donde el usuario está esperando no solo el tiempo de respuesta del servidor, luego para que el JavaScript se analice. Y cuanto más grandes y complejas se vuelven esas aplicaciones, y más lenta pueda ser tu red.

Ya sea porque no tienes una conexión de red rápida o estás en un dispositivo móvil antiguo que no es tan rápido, digamos. Cuanto más largo se vuelve este tiempo de espera. Y llegó al punto en que nos dimos cuenta de que podríamos haber ido un poco demasiado lejos con las aplicaciones completamente del lado del cliente y de una sola página.

Así que comenzamos a movernos de nuevo al servidor. Bueno, queríamos mantener todos los beneficios de todos esos buenos frameworks como React, como Vue que empezamos a disfrutar. Así que aprovechamos Node, que nos dio un entorno de ejecución de JavaScript en el servidor. Y la idea era que, cuando el navegador solicita una página, el servidor puede ejecutar el mismo framework en el servidor para generar la instantánea de ese HTML inicial.

Para dar una mejor respuesta inicial del servidor. Así que en lugar de simplemente devolver esa carcasa vacía, podemos devolver esa instantánea. Así que eso no tiene ninguna interactividad en ella. Porque el servidor no tiene un concepto de interactividad. Pero puede tener todos los elementos visuales. Y luego todavía devolvemos el JavaScript normal junto a ella.

Y el framework construirá una copia de la página en el cliente. Y luego inyectará todas las partes dinámicas en esa instantánea estática que inicialmente devolvimos. Así que esa inyección de partes dinámicas se llama hydration. Y esto es básicamente donde todos los frameworks hacen el trabajo pesado para inyectar las partes dinámicas.

Y luego toman el control desde allí. Donde si navegas después de esto, es mayormente como una aplicación de una sola página. Así que esto está tratando de obtener lo mejor de ambos mundos. Donde obtenemos una pintura inicial mejor y más rápida. Pero luego todavía tenemos que hacer la parte de hydration.

Y la parte de hydration puede ser realmente lenta. Porque, como dije, esencialmente estás construyendo la aplicación dos veces. Una vez en el servidor y luego en el cliente nuevamente. Para poder luego inyectar todas las partes dinámicas en ella. El segundo problema con este enfoque es que ahora estamos de vuelta en el servidor. Así que tenemos el problema original nuevamente de los días de HTML PHP. Donde si hacemos mucho trabajo en el servidor para obtener ese renderizado inicial. El tiempo de respuesta inicial del servidor puede volverse realmente lento, realmente rápido.

Entonces, ¿cómo resolvemos eso? Introdujimos componentes del servidor. Así que React se hizo un poco famoso por esto. Pero no fueron el único framework ni siquiera el primer framework en jugar con la idea. Pero fundamentalmente, el concepto es darle al empaquetador el conocimiento sobre qué componentes en nuestra aplicación. Realmente son dinámicos y realmente necesitan Javascript del lado del cliente. Y qué componentes son puramente estáticos y pueden ser renderizados una vez en el servidor y luego terminar con eso.

Y si miras tu aplicación a una escala mayor. La mayor parte de tu aplicación es estática. Y solo muy pocos componentes realmente necesitan cosas del lado del cliente como listeners de eventos, como estado local, etc. Así que la idea es que hacemos la solicitud al servidor. Todavía hacemos ese renderizado inicial en el servidor. Pero luego no necesitamos enviar toda la aplicación al cliente y volver a renderizar todo de nuevo. Podemos hacer lo que llamamos hidratación parcial.

Así que si el paquete sabe qué componentes son dinámicos, solo necesita enviar esos componentes dinámicos al cliente. Y solo esos necesitan ser hidratados y recibir su contenido dinámico inyectado. Ahora esta visualización podría parecer muy similar a lo que teníamos en los días de jQuery y Ajax. Porque fundamentalmente, todavía está tratando de hacer el mismo principio donde somos mucho más selectivos sobre lo que queremos hacer con el Javascript. Y dónde necesitamos Javascript. Y aquí es donde Internet y Google Fashion comenzaron a burlarse un poco de la idea diciendo, OK, entonces nuestro componente es solo PHP con un bonito árbol encima.

Y que estamos evolucionando pero hacia atrás. Y solo quiero mencionar eso porque creo que es una forma muy interesante de ver la progresión. Y en realidad creo que está mal. Creo que usar los mejores principios antiguos e ideas de tecnologías antiguas y aplicarlos a nuevas tecnologías y nuevas capacidades que vienen con esas tecnologías es en realidad una muy buena manera de evolucionar tu pila tecnológica. Así que en realidad creo que esta es una muy buena progresión. Nos metimos en Javascript. Hicimos todo dinámico. Y luego tomamos esos aprendizajes y tomamos los aprendizajes del pasado de cómo construir cosas en el servidor y los combinamos.

Todo esto es para decir que esto resuelve el tema de la hidratación. Con la hidratación parcial, el Javascript que necesitamos descargar es mucho más pequeño. La hidratación en sí misma es mucho más pequeña y mucho más rápida. Pero realmente no resuelve el segundo problema. Entonces, si el servidor hace mucho trabajo y la respuesta inicial del servidor es muy lenta, ¿cómo solucionamos eso? Ahora, para entender eso, construiremos una solución desde cero, como una solución muy simplificada desde cero nosotros mismos. Y para eso, vamos a mirar el renderizado tradicional del lado del servidor y a dónde nos lleva eso. Luego veremos algunas cosas como el streaming clásico y algunas de las limitaciones que vienen con él.

Y finalmente, echaremos un vistazo a cómo el autostreaming aborda esas limitaciones finales y qué nos da todo eso desde una perspectiva de DX, pero también desde una perspectiva de experiencia del usuario. Muy bien, escribamos algo de código. Para eso, preparé una pequeña aplicación de demostración. Es bastante simple. Es solo una aplicación de películas o programas de TV donde puedes ver un programa de TV, ver algunos detalles sobre él, de qué trata la trama, ver detalles sobre el elenco, y tal vez algunas películas y programas de TV similares que te podrían gustar si te gusta este. Se llama NotFlix. No quiero que me demanden. Pero puedes ver, si miras el código de esto, también trato de mantenerlo bastante simple. Así que esto es solo una aplicación de Express. Express realmente no importa aquí. Es solo la configuración de servidor más simple. Y estamos renderizando componentes individuales aquí para las diferentes secciones de la aplicación. Así que tenemos un componente para el encabezado, un componente para el título, imagen y detalles, luego un componente para el elenco, y un componente para las películas más simples. Y si miramos esos componentes, puedes ver que se parecen principalmente a componentes regulares de React. Podrías notar que son funciones asincrónicas, no funciones normales, porque estamos en el servidor.

Así que estoy tratando todos estos componentes como componentes del servidor que solo necesitan ejecutarse en el servidor una vez. Y en ese caso, podemos hacer cosas asincrónicas dentro de ellos, lo cual es bueno porque eso significa que la obtención de datos y cosas se pueden hacer directamente en línea. Así que en este caso, todos estos componentes irán al servidor para obtener las partes respectivas que necesitan de una API externa. Y no estamos en control de esa API, por lo que realmente no podemos hacerla más rápida. Pero estamos en control de nuestros componentes aquí.

Y luego en el servidor, lo que estoy haciendo ahora es básicamente lo que hace un renderizador clásico del lado del servidor. Estoy comenzando a recopilar el HTML, comenzando con la estructura del documento. Y luego este JSX me da un array de hijos. Así que luego simplemente recorro esos hijos. Como dije, todos estos hijos pueden ser asincrónicos. Así que esperamos, ejecutamos la función del componente con los props, y luego los renderizamos a cadenas. Estoy tomando eso de React. Y al final, estoy concatenando todas esas cadenas de todos los componentes. Estoy cerrando el texto del documento, y estoy enviando todo eso de vuelta al servidor.

Y si hacemos clic por aquí, veremos que eso funciona fundamentalmente. Pero si hago clic ahora, puedes notar que debido a que estamos haciendo muchas cosas asincrónicas y estamos obteniendo muchas cosas en el servidor, este tiempo de respuesta fue realmente lento. Y es frustrante desde una perspectiva de experiencia del usuario porque realmente no pasa nada hasta que se genera todo el HTML. Así que solo estoy mirando el spinner en el navegador hasta que llega la nueva página. Entonces, ¿cómo podemos mejorar eso? Como dije, el primer paso que podemos dar es simplemente el streaming clásico.

Con Express, todo lo que necesitamos hacer es usar el método rest o response write. Así que en lugar de hacer el send al final, podemos comenzar a escribir la respuesta. Y eso abre un stream pero mantiene el stream abierto para que podamos seguir escribiendo hasta que terminemos. Y luego solo necesitamos decirle que cierre el stream.

Si hacemos eso, queremos comenzar con el header. Y luego, en todos los lugares donde solo recopilamos HTML, ahora lo escribimos en ese stream que acabamos de abrir. Lo mismo con el texto de cierre. Y luego, como ya hemos escrito todo, todo lo que necesitamos hacer es terminar.

Así que esto le dice al navegador, oye, el stream ha terminado. Todo está cerrado ahora. Puedes dejar de escuchar al servidor. Y si ahora actualizamos la página, lo que veremos es que el logo se renderiza inmediatamente porque no hace nada asincrónico. Y luego vemos lo que esperábamos, como el contenido se transmite y cuando está listo.

Pero también ves que las secciones están un poco fuera de orden. Es algo esperado porque antes estábamos ejecutando todos esos componentes asíncronos en paralelo, porque podíamos, porque simplemente estábamos esperando todos ellos y luego uniéndolos. Ahora que los estamos transmitiendo cuando están listos, ya no podemos hacer eso.

Así que por ahora, para mantener las cosas simples, estoy reemplazando esto con un simple bucle for. Esta no es la forma más eficiente de hacerlo porque ahora estamos haciendo un componente asíncrono a la vez. Así que hay mejores maneras en las que podrías seguir ejecutándolos en paralelo pero luego resolverlos en el orden correcto. Pero para mantener las cosas simples para esta demo, usemos un bucle for. Y lo que hace es que nuevamente, vemos el logo y luego esperamos hasta que las secciones individuales lleguen.

Ahora, esto es definitivamente mucho mejor que la experiencia inicial. Sin embargo, todavía no es genial. Así que si hago clic ahora en la nueva cosa, obtengo la retroalimentación visual inmediata de que algo sucedió. Pero todavía estoy mirando principalmente una pantalla negra en blanco. Y lo que idealmente quiero es alguna forma de estado de carga. Así que alguna experiencia de esqueleto elegante que pueda usar para indicar al usuario que algo se está cargando. Y lo haría en el cliente usando suspense.

Y luego le damos algún tipo de fallback que nos permite renderizar ese estado de carga. Así que en este caso, tengo un componente de esqueleto preparado. Y básicamente, quiero renderizar este fallback mientras cualquiera de los hijos todavía hace sus cosas asíncronas. Entonces, ¿cómo haríamos eso en el servidor? Implementemos una versión muy simple de esto nosotros mismos para ver cómo funcionaría en un etherhoop.

Y para eso, primero necesitamos hacer un seguimiento de alguna forma de mapa u objeto donde podamos almacenar todos los elementos suspendidos. Todos esos componentes asíncronos que no podemos inmediatamente. Y luego hacemos el componente de suspense en sí, que realmente solo hace dos cosas. Una es que toma hijos como hemos visto y un fallback. Y lo que queremos hacer es poner esos hijos, como crear un ID único para cada instancia de este componente. Y luego almacenamos los hijos potencialmente asíncronos en ese mapa con el ID y solo renderizamos el fallback. Y almacenamos el ID de suspense aquí como un atributo de datos.

Vas a ver por qué en un segundo. Consejo de CSS al margen, le damos a ese diff que envolvemos todo en un display de contents. Lo que significa es que el navegador lo ignorará para cualquier propósito de diseño, por lo que no romperá ningún diseño de Git, grid o flex. Así que eso es bastante bueno. Pero si hacemos eso e importamos suspense aquí, lo que podemos hacer es simplemente refrescar la página y ver. Hace lo que queremos que haga, renderiza ese fallback.

Y ahora mismo no tenemos ninguna lógica aún para indicarle que reemplace ese fallback con el contenido una vez que esté listo. Así que vamos a añadir eso. Entonces tomamos ese objeto suspendido. Y verificamos si hay algún elemento en él. Y si es así, queremos renderizar esos elementos suspendidos. Y luego, una vez que están renderizados, hacemos lo que hemos hecho desde el principio. Simplemente concatenamos todos los hijos de cada uno de esos componentes de suspense y los escribimos en la cadena. Y si hacemos eso, fundamentalmente funciona. Hace lo que queremos que haga.

Así que ahora, una vez que el contenido está listo, aparece y se añade al flujo. Pero esa es la limitación fundamental del streaming clásico. Solo podemos añadir al flujo porque solo estamos añadiendo a ese documento transmitido que ya hemos comenzado a enviar al servidor. Entonces, ¿cómo podemos realmente reemplazar este estado de carga con el contenido real? La respuesta corta es que, en el streaming clásico, no podemos. Así que aquí es donde entra el streaming fuera de orden. Y para el streaming fuera de orden, necesitamos un poco de JavaScript, al menos por ahora. Así que hay dos cosas que queremos hacer aquí. Queremos envolver el contenido desde el límite de suspense, como el contenido suspendido, en una etiqueta de plantilla. Esto solo le dice al navegador que lo ignore para propósitos de renderizado, pero aún está en el DOM. Y luego queremos añadir lógica de JavaScript para reemplazar el marcador de posición con el contenido real una vez que esté listo.

Hay un millón de maneras diferentes de cómo podrías hacer esto. Para el propósito de esta demostración, voy a usar un elemento HTML personalizado. Y simplemente estamos renderizando eso después de la etiqueta de plantilla con el ID de destino. Ese es el ID de suspense, lo que nos permite luego vincularlo de nuevo al estado de carga con ese mismo ID. Por eso lo añadimos como un atributo de datos aquí. Así que ahora solo necesitamos el JavaScript para hacer la parte de reemplazo. Para hacer eso, esencialmente podemos hacer—el cursor está ayudando aquí—algo como esto. Así que estamos registrando ese elemento personalizado. Como dije, este es nuestro nombre de etiqueta que queremos, extendiendo el elemento HTML. Y todo lo que realmente necesitamos es un callback conectado. Este callback conectado se llama cada vez que este elemento personalizado se está renderizando, o cada instancia de él.

Entonces, cuando esto se ejecuta, queremos tomar el hermano anterior de nuestro elemento actual. Debido a que estamos en control del renderizado, sabemos que siempre será la etiqueta de plantilla a la que es relevante. Y obtenemos el ID del atributo de ID de destino. Luego buscamos en el DOM ese ID de suspense de datos desde el límite de suspense. Así que básicamente estamos buscando el estado de carga que pertenece a ese ID. Y luego limpiamos el HTML de ese estado de carga y lo reemplazamos con el HTML de esa etiqueta de plantilla. Así que bastante sencillo, solo unas pocas líneas de JavaScript.

Pero lo que hace es básicamente darnos exactamente lo que queremos. Cuando actualizamos la página, tenemos inmediatamente el estado de carga disponible. Y luego se reemplaza por el contenido real una vez que está allí. Y nuevamente, cuando hago clic en un enlace, obtengo inmediatamente ese agradable estado de carga. Y todo lo demás entra. Y no estamos limitados a un solo límite de suspense tampoco. Podemos tener fácilmente múltiples de estos para cada una de las secciones. Así que solo recomendaría eso si sabes exactamente las alturas de cada una de esas secciones para minimizar el cambio de diseño.

Pero si conoces tus alturas, puedes hacer esto y luego tener una experiencia de carga mucho más rica. Y luego puedes permitir que las cosas aparezcan en el momento en que estén listas. No tienes que esperar a que todas estas secciones estén listas para reemplazar tus límites de carga individuales, lo cual es bastante genial. La otra cosa genial que obtienes con esto es que, como es streaming y todo viene del servidor, obtienes mucha funcionalidad genial del navegador esencialmente gratis. Lo que quiero decir con eso son cosas como el almacenamiento en caché y el historial hacia atrás y hacia adelante. Así que si ahora que esto está cargado, retrocedo en el historial, ves que esto es inmediato.