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 hablas sobre el rendimiento web, especialmente en estos días, la conversación generalmente muy rápidamente se desvía hacia cosas como el server-side rendering e 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 server-side rendering tradicional y el streaming, y luego específicamente profundizar en cómo el out-of-order streaming resuelve algunas de esas limitaciones para que, con suerte, al final de esto, no solo tengas una idea de qué es el out-of-order streaming y cómo funciona, bajo el capó, 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 donde te voy a decir que tienes que usar el server-side rendering y el out-of-order streaming 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 aún así tomar una decisión 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 out-of-order streaming? Para entender eso, necesitamos echar un vistazo rápido a la historia del renderizado web y cómo llegamos a donde estamos hoy. Tenemos que comenzar desde el principio, lo que 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. 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. 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 estamos 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. Esto es realmente frustrante para las páginas donde hacemos más en el servidor. Así que intentamos resolver ese problema introduciendo JavaScript o más. Específicamente, esta es una especie de era de jQuery y la introducción de tecnologías como Ajax. Así que estamos hablando del año 2006 aproximadamente. 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 aún devuelve HTML estático. Pero ahora el servidor también puede devolver un archivo JavaScript. Y luego el navegador pausa y ejecuta el archivo JavaScript. Y ese JavaScript podría inyectar algunos event listeners para manejadores de clic 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 una experiencia general del usuario. Pero para resolver ese largo tiempo de espera cuando navegas, la introducción de Ajax realmente ayudó. Así que 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 es 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 podríamos querer mostrar mientras el usuario espera que ese contenido llegue, lo que mejora enormemente la experiencia del usuario en esas lecturas de navegación.

Ahora, una vez que introducimos JavaScript al 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 jQuery simple. Luego rápidamente construimos frameworks de aplicaciones que nos ayudaron a construir la forma de aplicaciones normales 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 el servidor por completo. Así que ahora, cuando solicitamos una página, todo lo que realmente hace el servidor es devolver un contenedor vacío con tus documentos para compartir, 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 todo el JavaScript está 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 barrera 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 construir 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 si 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.

El verdadero inconveniente aquí es esa carga inicial donde el usuario está esperando, no solo por el tiempo de respuesta del servidor, sino también por el tiempo que tarda en pasar el JavaScript. Cuanto más grandes y complejas se vuelven esas aplicaciones y más lenta puede ser tu red, ya sea porque no tienes una conexión de red rápida o estás en un dispositivo móvil antiguo no tan rápido, más largo se vuelve este tiempo de espera. Llegó al punto en que nos dimos cuenta de que quizás habíamos 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 regreso al servidor. Pero queríamos mantener todos los beneficios de todos esos agradables frameworks como React, como Vue que comenzamos a disfrutar. Así que aprovechamos Node, que nos dio un entorno de ejecución de JavaScript en el servidor. Y la idea era, 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 solo devolver ese contenedor vacío, podemos devolver esa instantánea. Así que eso no tiene ninguna interactividad porque por definición, el servidor no tiene un concepto de interactividad. Pero puede tener todos los elementos visuales. Y luego todavía devolvemos el JavaScript normal junto con él 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 hidratación. Y esto es básicamente donde todos los frameworks hacen el trabajo pesado para inyectar las partes dinámicas y luego tomar el control desde allí donde si navegas después de esto, se siente principalmente como una aplicación de una sola página. Así que esto está tratando de obtener lo mejor de ambos mundos donde obtenemos un mejor y más rápido pintado inicial, pero luego todavía tenemos que hacer la parte de la hidratación.

Y la parte de la hidratación puede ser realmente lenta porque, como dije, estás esencialmente construyendo la aplicación dos veces, ¿verdad? 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?

Introducimos componentes del servidor. Así que React se hizo famoso por esto, pero no fueron el único framework o 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 son realmente 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 ellos. Y si echas un vistazo a tu aplicación a gran escala, como 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 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 e inyectar sus cosas dinámicas.

Ahora esta visualización podría parecer muy similar a lo que teníamos en los días de jQuery y Ajax, ¿verdad? 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 el internet y la moda de Google comenzaron a burlarse un poco de la idea diciendo, ah, está bien, entonces un componente es solo PHP. Ooh, el bonito árbol ocurrió encima de él. Y que estamos evolucionando, pero hacia atrás.

Y solo quiero mencionar eso porque creo que es solo una forma muy interesante de ver la progresión, y en realidad creo que está mal. Como, creo que usar los mejores principios antiguos e ideas de tecnologías antiguas y aplicarlas a nuevas tecnologías y nuevas capacidades que vienen con esas tecnologías es en realidad una muy buena manera de evolucionar.

Um tu stack tecnológico. Así que en realidad creo que esta es una muy buena progresión a través de la cual llegamos a JavaScript, conseguimos 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, esto resuelve el problema de la hidratación con hidratación parcial, ese 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. Así que si el servidor hace mucho trabajo y la respuesta inicial del servidor es realmente 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 auto-streaming aborda esas limitaciones finales y lo que todo eso nos da desde una perspectiva de DX, pero también desde una perspectiva de experiencia de usuario. Muy bien. Vamos a escribir algo de código. Para eso, preparé una pequeña aplicación de demostración. Es bastante simple. Es solo una especie de 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 traté 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 servicio más simple. Y estamos renderizando componentes individuales aquí para las diferentes secciones de la aplicación. Así que tenemos un componente para el header, 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. Si miramos esos componentes, puedes ver que se parecen principalmente a componentes de React regulares.

Podrías notar que son funciones asíncronas, 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 asíncronas 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 sus respectivas partes que necesitan de una API externa.

Y no estamos en control de esa API, así 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, así que solo comenzando con la estructura del documento, y luego este JSX me da un array de hijos. Así que luego solo recorro esos hijos. Como dije, todos estos hijos pueden ser asíncronos. Así que esperamos, ejecutamos la función, básicamente la función del componente, con nuestros props, y luego los renderizamos a cadenas. Estoy tomando eso de React on.

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 asíncronas, y estamos obteniendo muchas cosas en el servidor, este tiempo de respuesta fue realmente lento. Es frustrante desde una perspectiva de experiencia de usuario porque realmente no pasa nada hasta que todo el HTML está generado.

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. Y en Node, eso es bastante fácil. 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.

Y luego, como ya hemos escrito todo, lo único 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 asíncrono. Y luego vemos lo que esperábamos, como los streams de contenido 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 de ejecutarlos en paralelo, pero luego resolverlos en el orden correcto. Pero para mantener las cosas simples para esta demostración, 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, ¿verdad? Así que alguna experiencia de esqueleto elegante que pueda usar para indicar al usuario que algo se está cargando. Y cómo lo haría en el cliente es usar suspense. Y luego le damos algún tipo de fallback que nos permita renderizar ese estado de carga. 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 por debajo. 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 del componente de suspense, 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á ninguna disposición de 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 que hace más o menos lo que queremos hacer. Renderiza ese fallback. Y ahora mismo no tenemos ninguna lógica aún para decirle que reemplace ese fallback con el contenido una vez que esté listo.

Así que añadamos 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 se renderizan, hacemos lo que hicimos al 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, eso funciona. Hace lo que queremos que haga. Así que ahora, una vez que el contenido está listo, aparece en existencia y se añade al stream. Pero esa es la limitación fundamental del streaming clásico, ¿verdad? Solo podemos añadir al stream porque solo estamos dependiendo de 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. 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 editamos 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 cursores 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 para cada instancia de él. Así que cuando esto se ejecuta, queremos tomar el hermano anterior de nuestro elemento actual, porque estamos en control del renderizado. Sabemos que siempre va a ser la etiqueta de plantilla que es relevante para ello.

Luego 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 estamos limpiando el HTML de ese estado de carga y reemplazándolo con el HTML de esa etiqueta de plantilla. Así que bastante sencillo, solo unas pocas líneas de JavaScript. Pero lo que eso 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 llega. Y no estamos limitados a un solo límite de suspense tampoco. Podemos fácilmente tener 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 las 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 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.