Out Of Order Streaming (El Secreto que Impulsa el React Moderno)

♪♪♪ Tuve que hacer una corrección rápida. No leyó el copyright. Soy el segundo mejor YouTuber de TypeScript. Solo quería aclarar. No voy a robar el valor de Matt Pelcock. Es muy bueno en lo que hace.

Pero para aquellos que no me conocen, soy Theo. He estado haciendo videos de desarrollo de software durante unos dos años. ¿Y quién ha visto uno de mis videos antes? ¡Sí! ¡Woo! Un buen número de ustedes. Buen material. No sé por qué.

Entonces, hoy estoy dando mi charla sobre streaming y no solo en React, sino en general por qué es genial y los beneficios de agregar streaming a tus aplicaciones. Y estoy haciendo eso, ante todo, mostrándote una aplicación normal de React escrita de la manera en que muchos de nosotros la hemos escrito antes. Solo actualizo la página, vemos la carga y tenemos nuestro estado de sesión iniciada. Todos hemos escrito código como este antes, con suerte. Tal vez no, en realidad. Veamos.

¿Quién ha escrito código como este antes? Veamos manos. No puedo ver las manos porque literalmente solo tengo una caja negra aquí, pero confío en que hay un buen número de ellas. Si has escrito código como este, muévete a React Query.

De todos modos, este código funciona bien. La página se carga, tiene una etiqueta de JavaScript en ella, el navegador carga la etiqueta de JavaScript, el JavaScript se analiza, renderiza el componente, se da cuenta, oh, necesito ir a buscar estos datos. Y luego va y hace la solicitud de API, obtiene los datos, los establece en un estado y luego vuelve a renderizar con el nuevo estado actualizado. Sin embargo, hay un par de problemas aquí. Obviamente, hay condiciones de carrera y demás. Vamos a ignorarlas. El problema principal es que tengo que esperar hasta que la página haya cargado el HTML, obtener el JavaScript, analizar el JavaScript, ejecutar el JavaScript, renderizar el componente, y luego finalmente podemos comenzar la obtención cuando podríamos haber estado haciendo todo ese trabajo durante ese tiempo antes. ¿Cómo, sin embargo? Porque necesitamos tener este contenido en la página. No podemos simplemente enviar algo de HTML y enviar el resto más tarde. ¿O sí podemos? Hay una pequeña demostración maravillosa que Guillermo tuiteó hace un tiempo.

Iba a copiar y pegar el código, pero todos hemos usado la captura de pantalla de texto antes. No funciona, y no tenía ganas de codificarlo.

Los detalles importantes aquí son que tenemos un stream, escribimos estos datos de stream como escribibles con este waitUntil, pero inmediatamente enviamos una respuesta que tiene el tipo de contenido HTML. Luego, en esta función de datos de stream, creamos un escritor, escribimos inmediatamente un poco de HTML, esperamos 1.5 segundos, luego obtenemos esta URL de confeti y te mostramos el resto después.

Ahora, cómo se ve esto, si cargo esta página, dice, hola, y luego aparece el mundo. Donde las cosas se ponen interesantes es si entramos en la pestaña de red y hacemos lo mismo, podrías haber notado aquí, va a ser difícil de ver, así que en realidad copié el código, para que podamos echar un vistazo en un segundo. El HTML llega... Necesito desactivar el caché allí, recargar esto. El HTML llega parcialmente completo. Se detiene aquí, y luego el resto del HTML llega después. Bastante genial. La forma en que esto funciona es que el navegador es lo suficientemente inteligente para renderizar HTML incompleto, siempre que tenga una etiqueta de cierre para el elemento más reciente. Puedes simplemente enviar HTML incompleto, el navegador puede renderizarlo, y puedes terminar el HTML más tarde.

Eso es genial si tienes todo tu contenido en orden. Llegaremos a la parte desordenada en un minuto.

Así que, aquí tengo la versión moderna del componente del servidor de este código. Obtengo el usuario directamente de la base de datos. Este código es muy sofisticado, como podemos ver aquí. Espero tres segundos y luego devuelvo un usuario falso. Cuando cargo esto, si cierro y vuelvo a abrir esa página, estoy aquí esperando. ¿Ves el pequeño indicador de carga en la parte superior? Tienes que esperar los tres segundos completos antes de ver algo. Lo que encontré como desarrollador y como usuario es que la mayoría de las personas percibirán este sitio web como mucho más lento que un sitio web que carga todo el JavaScript de inmediato porque puedes ver algo inmediatamente. Si vas a una página web que tiene el HTML almacenado en caché en un CDN para que puedas obtener esa parte instantáneamente, hace que la navegación se sienta más rápida, incluso si solo ves un indicador de carga inmediatamente después. Por eso soportamos las peculiaridades y comportamientos de las aplicaciones de una sola página durante tanto tiempo, porque obtendríamos esa respuesta inmediata, esperaríamos a que el JS se cargara, lo tendríamos en nuestro caché, y luego todo lo demás es lo suficientemente rápido. Pero lo más importante es que harías clic en un botón y verías la respuesta de inmediato, lo cual si cierro y vuelvo a abrir esto, no estoy viendo una respuesta de inmediato. Esto está tomando un tiempo considerable.

Entonces, ¿cómo resolvemos esto? ¿Quién conoce la solución moderna a este problema en la audiencia? Veamos manos levantadas. Aún no veo manos. ¿Qué tal si la gente grita, cuál es la solución a este problema? ¿Cuál es el componente que necesito agregar para solucionar esto? Correcto. Necesito mover esta parte rápidamente, lo cual podemos hacer fácilmente.

Function, user, data. Toma eso. Solo haz esto asincrónico. Luego devuelve. Veamos si un cursor puede llevarme aquí. Genial, puede. Y cambiamos esto. Error usuario no está definido. Oh, porque era el estado antiguo. Porque es gracioso. Incluso obtienes los mismos problemas cuando estás depurando. Porque tomó tres segundos salir de la página de estado de error para llegar a la página que funciona nuevamente. Así que pensé que mi código estaba mal, cuando en realidad, el navegador estaba retrasado.

Y ahora todo lo que tenemos que hacer es envolver esto con un suspense. Fallback está cargando. Olvidé importarlo. Y ahora obtenemos ese estado de carga inmediatamente. Y si cierro y vuelvo a abrir, vemos eso. Pero también vemos el indicador de carga, porque el navegador aún no ha terminado de enviar el HTML. Si nuevamente abro la pestaña de red y actualizo esto, saltamos aquí. Verás que esta es una etiqueta HTML incompleta. Puedo probar eso agregando un 0. Limpia esto. Recarga. Y ahora verás que tenemos este HTML incompleto. No ha terminado de enviarse.

Pero en un momento, va a enviar el resto del HTML. Probablemente debería haberlo hecho no 30 segundos. Hagámoslo 5. Me da suficiente tiempo para maniobrar rápidamente a través de DevTools. Esto es molesto de demostrar, he aprendido rápidamente, porque tienes que entrar en DevTools antes de que llegue el resto y luego te reinicia en la parte superior así que no ves dónde estabas desplazado. Eso es raro.

¿Por qué está este div oculto? Bueno, si tu HTML no está en orden de más rápido a más lento, resulta que el streaming no es particularmente útil. Porque si, digamos, en lugar de que el estado de inicio de sesión esté debajo del contenido estático, esto estuviera arriba. No podemos simplemente enviar esa parte más tarde porque está en el orden. HTML es un formato lineal. Podríamos hacer algunos trucos de CSS para cambiar las cosas. He visto irónicamente código así antes que es aterrador. Pero, ¿y si no tuviéramos que hacerlo? ¿Y si el orden en que las cosas se transmiten al navegador no tuviera que coincidir perfectamente con el orden en que aparecían en el HTML, y luego eventualmente en el DOM, de la forma en que el usuario lo vería? Este ha sido un desafío que hemos estado tratando de encontrar una buena solución confiable para nosotros, los entusiastas del streaming, durante un tiempo. Y he hecho algunas cosas tontas antes en Cloudflare. Espero que ninguno de ustedes haya tenido que hacer eso. No fue divertido.

Pero hay algo de JavaScript mágico aquí que hace que todo esto funcione. Y podría mostrarles cómo funciona, pero creo que es más divertido mostrarles cómo se rompe. Así que vamos a abrir esta versión de la página que tiene un par de piezas adicionales. No ocultas. Así que ahora tenemos estos tres componentes lentos. Componente lento uno, luego dos, luego tres. Nuevamente, código muy complejo. Les paso una prop que es el tiempo de espera para cuánto tiempo se supone que deben ser. También, debería haber mencionado esto antes. Todo este código es código del servidor. Ninguno de los JavaScript que ves aquí se envía al cliente. Si tuviera que usar client en la parte superior, simplemente se rompería por completo porque son componentes recientes. Pero aquí tenemos el uno, luego el dos, luego el tres. Y también puedo cambiar el orden de estos.

Podría hacer tres, dos, uno. Y aparecerán en la parte inferior, medio, superior. Así que claramente esto no está llegando de manera lineal. Vamos a romperlo. Podría haber escrito este código en vivo, pero se ve así, así que no lo voy a hacer. Vamos a saltar rápidamente a la versión oculta. Y ahora vemos uno, luego dos, luego signo de dólar componente lento tres.

Echemos un vistazo a las DevTools. Así que si entramos aquí, actualizo de nuevo. Limpio y actualizo una vez más. Verás que el HTML está llegando aquí. Y tenemos todos mis divs, estados de carga. Pero también tenemos esta pieza importante aquí, esta etiqueta script. He pasado demasiado tiempo pensando en esta etiqueta script en particular y enseñando a personas que trabajan en otras cosas como Elixir la importancia de esta etiqueta script. ¿Puedo decirle a esto que esto es JavaScript, incluso si no quiere creerlo? Genial. Esta es una función mágica que se envía la primera vez que Next.js transmite HTML adicional al navegador. Toma un elemento por ID. Define esta función RC, que toma un elemento por su ID. Elimina el hijo. Así que esto se está eliminando a sí mismo porque va al padre y luego lo elimina. Encontramos este elemento B. Y hacemos un montón de código maravilloso para intercambiar estos y cambiar este elemento por este otro elemento. Y luego tenemos aquí mismo $rc B: 0, S: 0.

Si vuelvo a esto, cambiaré esto a ser 5, 6. Seguro. Así que es un poco más lento. Ocultar a estos chicos. Y cambiar esto a ser 0. Recargaremos aquí. Y verás un poco lo que está sucediendo aquí.

Esperamos los seis segundos. Y obtenemos el div falso siendo reemplazado. Porque lo que habría existido en el HTML antes, lo cual es relativamente fácil de mostrar, está en este HTML, donde está ese estado de carga, tenemos la plantilla ID B0. Y así es como el HTML sabe dónde este elemento necesita ser intercambiado. Así que cuando pones un suspense usando componentes del servidor, React colocará una de estas plantillas para cada uno de esos puntos e identificarlos en el orden en que fueron creados. Y luego, cuando React termina de resolver ese límite de suspense y sabe que estos datos están listos, envía ese HTML con un ID S: algún número para intercambiarlo.

Así que el orden en que estas cosas llegan es que obtenemos el HTML que no tiene nada envolviéndolo en suspense. Una vez que uno de estos límites de suspense se resuelve y está listo, enviamos este div oculto que tiene el ID para coincidir con este otro elemento, contiene el HTML real dentro de él. Y luego, si no hemos enviado esta etiqueta de script RC aún, la enviamos inmediatamente después con esta función. Y luego se invoca a sí misma para intercambiar esos elementos. Esto nos permite enviar el HTML en cualquier orden e intercambiarlo en cualquier punto. Y esto no solo beneficia a React, no solo beneficia a JavaScript. He estado ayudando al equipo de Phoenix LiveView en el mundo de Elixir a implementar esto allí para que puedan enviar su plantilla, pueden enviar su diseño inmediatamente, y luego enviar el resto de los datos después de cualquier llamada a la base de datos o autenticación u otras cosas estén hechas, lo que hará que tu sitio se sienta mucho más rápido, especialmente si puedes almacenar en caché esa primera parte en un CDN y luego resolver el resto a medida que avanzas. Y si volvemos aquí rápidamente, y los vuelvo a encender todos, limpio eso, donde las cosas se optimizan realmente y, en mi opinión, se vuelven realmente interesantes, es una vez que has enviado este primer fragmento con este primer HTML, el resto se puede enviar sin esa etiqueta de script, y simplemente se llama así. Así que para S2, porque eso llegó después, envía el HTML, luego envía la etiqueta de script con estos datos, y luego envía, ya que estamos en Next.js, los metadatos necesarios para que Next haga un seguimiento de lo que está en el DOM donde, maneje la hidratación, todas esas cosas. Y tenemos el tercero que llega, y hace exactamente lo mismo. Creo que esto es súper genial, y los patrones que habilita son fenomenales. Voy a arriesgarme e ir un paso más allá, sin embargo, porque tengo más tiempo del que pensé que tendría en este punto. Así que vamos a hacer algo realmente tonto. Vamos a instalar Next Canary. No es que ya no esté en un canary, pero no estamos en el último. Y vamos a activar experimental, y mira eso. Lo que acabamos de hacer es hacer que esto sea ahora un comportamiento predeterminado, lo que permite ese maravilloso comportamiento de caché que estaba describiendo antes.

Así que si volvemos, tenemos la página de inicio. Esto debería funcionar, con suerte, si todo va bien. Genial. Lo que acabo de activar es una característica nueva y realmente genial llamada dynamic I.O. Anteriormente, habrías tenido que decirle a React, o Next.js, o cualquier conjunto de herramientas que estés usando, dónde existen estos límites usando una etiqueta de suspense. Pero ahora, puedo eliminar el async aquí, porque realmente ya no lo necesito. Y tenemos el suspense. Puedo dejar eso.

Ahora, si fuéramos a construir este proyecto, obtenemos activos de salida muy diferentes, porque el mayor problema con el streaming es que el primer byte tiene que ser resuelto por el mismo servidor que envía el resto. Así que si voy a una página web, y está siendo servida con componentes del servidor, no puedo obtener algo de un CDN inmediatamente. Necesito tener una conexión con ese servidor para que pueda enviar todo lo demás. Esto es bueno, porque tienes esa única fuente de verdad que proporciona todo el contenido para la página. Te permite enviar algunos datos por adelantado. Incluso si tu sitio es completamente dinámico, al menos puedes comenzar a cargar las etiquetas de script, las fuentes, el CSS, y todas esas cosas antes. Pero todavía estás bloqueado en un servidor. Si estás usando Lambda, algo así, tiene que activarse, procesar la solicitud, averiguar qué respuesta comenzar a enviar, comenzar a generar el resto, y lo envía todo. Pero si ejecuto bun run build después de activar dynamic I-O, obtenemos un pequeño error agradable.

Oh, porque todavía tengo un montón de esas etiquetas force dynamic, que ya no son necesarias, lo cual es un cambio realmente genial. Con suerte, eso es suficiente. ¿O tengo una en hidden también? Sí, la tengo. Y, por supuesto, las cosas ya no se están usando. A la quinta va la vencida. Ahí estamos.

Lo que hemos hecho aquí que es súper genial, verás ese círculo mitad y mitad. Esta página está parcialmente pre-renderizada. Así que tienes pre-renderizado, que está generando HTML basado en qué props esperas que tenga una página. Tienes renderizado dinámico, que es toda la página renderizada dinámicamente al vuelo. Pero ahora tenemos pre-renderizado parcial, donde tomamos todo hasta la primera etiqueta de suspense, lo renderizamos estáticamente y lo almacenamos en un CDN. Y ahora, cuando el usuario va a la página, esa parte puede cargarse inmediatamente. Pueden empezar a ver algo. Podría ser un estado de carga. Podría ser una página en blanco. Pero al menos ya están cargando las fuentes, el CSS, y todas esas otras cosas, mientras tu servidor se activa y comienza a generar el resto.

Pero, ¿cómo funciona eso? Debe haber algunos trucos locos de compilador, ¿verdad? Tengo un video que saldrá pronto del que estoy realmente orgulloso sobre la magia que impulsa esta característica y cómo habilita todas estas cosas. Pero el TLDR es la bandera principal que están usando para identificar lo que se puede o no renderizar de esta manera. Es async. Ya estamos pintando el código. Ya estamos diciendo a las herramientas que estamos usando qué es o no es async, lo que significa, teóricamente, que hay algún trabajo que debe hacerse allí. Así que ahora sabemos dónde comienza este trabajo, porque se llamó a una función async. E incluso les dimos una pista extra. Agregamos una etiqueta de suspense. Ahora todo lo que se necesita para renderizar esa parte estática está listo para usar. Podemos renderizarlo, guardarlo en un CDN. Y luego, en adelante, todo puede ser renderizado en el servidor. Simplemente consume ese HTML inicial y luego transmite el resto con el pequeño intercambio mágico que vimos con esa función RC.

Espero que esto ayude a aclarar tanto por qué el streaming es tan importante, como cómo realmente funciona, y cómo React ha trabajado alrededor de las limitaciones del protocolo. Porque resulta que hacer streaming de HTML en orden realmente no te da una gran experiencia para tus usuarios.

Tendremos un poco de JavaScript moviendo algunos elementos aquí y allá. De repente, este patrón se convierte en una mejor manera de navegar por la web.

Gracias a todos. Esto parece una característica increíble para la métrica central de cambio de diseño. ¿Crees que eso es cierto? Absolutamente. Para ser claros, anteriormente, cuando las cosas se transmitían de arriba a abajo, causaba cambio de diseño seguro. Pero ahora, es relativamente fácil tomar algo que es lento, envolverlo con un suspense, darle una etiqueta de fallback que tenga el mismo tamaño que el elemento de salida esperado, y simplemente funciona. Ya no tienes que pensar en ello, lo cual es realmente, realmente genial. Y eso no solo sucede para ejemplos raros.

En nuestro producto de carga, que es simplemente mejores cargas de archivos para desarrolladores full stack, tenemos pequeños fondos para todas las aplicaciones que has creado. Y esos fondos son SVGs, muchos de los cuales son grandes. Tengo, creo, 800 de ellos en un archivo. Es como un megabyte y medio de TypeScript. Así que cuando cargas la página que tiene esos datos, tenemos el contenedor en el exterior, el pequeño spinner de carga para el estado en la página allí. Y podemos transmitir todas las aplicaciones que tienes en tu cuenta con el SVG en línea en eso también. Así que no tenemos que enviarte esto con una etiqueta de imagen que tiene que ir a buscar un SVG y luego cargarlo. Tal vez sea del tamaño incorrecto y todo eso. En su lugar, simplemente enviamos eso como parte del HTML transmitido. Sin aparición repentina, sin comportamientos extraños. Todo simplemente funciona. Y he estado impresionado con los nuevos patrones de suspense y cómo se siente antinatural.

Genial. Como novato en SSR y Next, ¿cómo depuro este HTML incompleto en la pestaña Source de Chrome? No lo haces. Casi todos los desarrolladores de Next.js que conozco que están usando estas características no saben cómo realmente funciona bajo el capó. Solo lo aprendí hace poco, porque estaba ayudando a mis amigos del mundo de Elixir a hacer ingeniería inversa para copiarlo en lo que estaban haciendo. Nunca deberías necesitar mirar la pestaña Network de esa manera. Hay una razón por la que fue tan difícil para mí hacerlo. No importa. Si encuentras un error relacionado con el orden en que el HTML se está transmitiendo a través de React, por favor envíame un DM. Estoy realmente curioso.

Pero parece un modelo bastante infalible.

Siguiente. ¿Cuál es la historia para el CDN que no es Vercel? Gran pregunta. Resulta que es realmente difícil enviar contenido a alguien en el borde a través de algo como un CDN mientras también se renderiza lo mismo, como el resto del contenido, cerca de tu base de datos. Así que si mi usuario está aquí, mis datos están aquí, idealmente mi servidor está justo cerca de los datos, porque habrá múltiples idas y venidas. Pero el CDN debería estar mucho más cerca de donde está el usuario. Así que ahora necesitamos tener una manera de resolver las partes estáticas cerca del usuario y resolver las partes dinámicas lejos del usuario y también entremezclar el tráfico, porque el servidor no va a saber enviar solo las partes transmitidas. Va a querer enviar todo. Puedes hacer esto tú mismo en una plataforma como Cloudflare o Fastly poniendo una función de JavaScript allí que enviará el fragmento inicial desde el CDN tan pronto como hagas una solicitud, activar tu lambda o lo que sea para comenzar a generar el resto. Consume todo hasta ese primer div oculto, y luego envía el resto de esa manera. He trabajado en hacer esto yo mismo una vez antes. No es divertido. Estoy emocionado por un futuro donde sea más fácil implementar estas cosas. Pero resulta que hacer buenos y poderosos patrones de renderizado en el lado de la infraestructura es difícil. Y hay una razón por la que Vercel es la cosa que todos terminamos usando. Sé que Netlify también está trabajando en muchas de estas cosas. Es divertido jugar con esto, pero hacerlo tú mismo no es divertido en este momento.

Muy bien, el siguiente. ¿Qué piensas sobre usar suspense para manejar objetos de promesa en el renderizado del lado del cliente? Seré honesto. Más allá de cosas como React 3.0 Fiber, no he usado mucho suspense en el lado del cliente. Probablemente tuve tres o cuatro envoltorios de suspense en mis aplicaciones antes de los componentes del servidor, y todos ellos eran para carga diferida de componentes gigantes con un montón de JavaScript en ellos. Es un patrón genial. Nunca he logrado que el hook use en React se comporte correctamente. No es algo que haya explorado tanto como me hubiera gustado aún, pero parece bien.

Algo más que realmente creo que es muy genial, debería haberme centrado en la demostración. Piensa en eso para el futuro. No solo tienes la capacidad de pasar JSX desde el servidor. No es solo como, oh, renderizo algo de HTML en un suspense y baja después. También puedes tomar una promesa que está en el servidor, como la promesa de usuario que tenía, y pasar la promesa en sí al cliente a través de un componente cliente, solo como una prop. Si tengo mi getUserPromise en el servidor, paso eso a un componente cliente. Puedo envolver esa promesa en use, y ahora tengo la capacidad de obtener el resultado de la promesa transmitido al cliente en lugar de solo transmitir el JSX, lo cual es una forma realmente genial de hacer las cosas en el cliente mientras aún se obtiene los datos del servidor y se pasan.

¿Esto ayudará al LCP o solo a la velocidad percibida del sitio? Esto definitivamente ayudará al LCP. No es una ayuda masiva, pero el momento en que más ayuda es la primera vez que has cargado la página, porque ya no estás bloqueado en la carga de JavaScript y luego obteniendo el resto del contenido. Puedes pensar en ello como, antes teníamos la carga de la página. Activaría la carga de HTML. Activaría la carga de JavaScript, el CSS, y todo eso. Haría todo su análisis, y luego comenzaría a obtener. Hemos tomado esta parte y simplemente la hemos movido aquí, porque la obtención puede comenzar antes de que el navegador termine de analizar todas esas cosas. Así que la cantidad de tiempo que lleva llegar a ese estado final es mejor, pero esto solía venir al costo de tu primer Contentful Paint, porque tendrías que esperar a que el servidor se activara y comenzara a enviar una respuesta. Ahora podríamos enviar una respuesta inmediatamente y comenzar a generar el resto de la página todo simplemente desplazado. Pasamos de algo así a esto para nuestras líneas de tiempo, lo que permite que todo sea más rápido. Genial. Veamos. Vamos a encontrar uno bueno aquí. Muy bien, revisemos esto. ¿Hay una manera fácil de ver la jerarquía de componentes y entender cómo y cuándo Next.js obtiene datos y renderiza componentes? No. Este ha sido un problema del que me he quejado durante un tiempo.

Honestamente, creo que gran parte de la resistencia con el nuevo modelo de Next.js React proviene de que las herramientas de desarrollo no se han puesto al día tan rápido como las capacidades lo han hecho. Y cuando obtienes capacidades como esta, tu código se vuelve mucho más simple, pero tan pronto como creas herramientas que simplifican las cosas, la gente ahora puede hacer cosas cada vez más complejas, porque los primitivos básicos son mejores.

Como resultado, era fácil llegar a un punto donde realmente no sabías qué se estaba obteniendo, qué no, qué datos existían dónde, la jerarquía de todo eso en tu aplicación, y ya no podíamos simplemente depurar con herramientas de desarrollo en el navegador como estamos acostumbrados porque tus herramientas de desarrollo en el navegador no te dicen lo que el servidor está haciendo. Se está trabajando para solucionar mucho de esto. Sé que el equipo de Next. finalmente está realmente comprometido a resolver el problema de las herramientas de desarrollo, pero no está donde me gustaría que estuviera ahora mismo. Y cuando miro cosas como el mundo de NUXT y Vue, siento un poco de envidia por la calidad de sus herramientas de desarrollo.

Sí. OK. ¿Cómo interactúa esto con páginas fuertemente en caché? Hay muchos lugares diferentes donde puedes poner caché. Y siempre es difícil cuando la gente me pregunta sobre ello, porque no sé si estás hablando de un servicio de back-end que está obteniendo datos de una base de datos a la que estás poniendo una caché frente a las respuestas, ¿estás tratando de hacer caché de las funciones que estás llamando que obtienen datos en tu back-end para la aplicación del lado del servidor de React, o estás tratando de hacer caché del HTML que está en el frente que los usuarios están obteniendo en ese extremo?

Depende de dónde estés poniendo la caché. Encuentro que el patrón de poner la caché frente a la respuesta HTML es muy inflexible. Y requiere que toda la página sea lo suficientemente estática para que cada usuario pueda obtener el mismo HTML. Eso, por muchas razones, apesta. Significa que solo puedes tener un estado de página que cada usuario obtiene. Con este nuevo patrón, técnicamente, no estamos en caché en el sentido tradicional de CDN, pero podemos obtener esa primera respuesta mucho más rápido. Esa respuesta será genérica, pero será solo un cargador, sea cual sea el estado de la página, y el resto puede comenzar a ser transmitido, y qué partes de eso haces caché depende de ti.

Encuentro que nosotros, como desarrolladores web, hemos sido forzados a pensar en la caché como los encabezados que ponemos en nuestro HTML. Ahora podemos pensar en la caché a un nivel mucho más granular. O no. Tenemos la capacidad de elegir. De la misma manera que React nos permite elegir MVC o no, la caché ahora está dividida de manera similar. No deberíamos tener que pensar en la caché como la cosa que sucede después de que el HTML se carga. Bien, el siguiente. ¿Esto afecta al SEO? Quiero decir, estos rastreadores, quiero decir, ¿estos rastreadores son lo suficientemente pacientes para esperar el estado final? Casi todos lo son, sí. Y si no lo son, tienen suficientes datos para hacer cosas. He encontrado que el SEO en nuestras aplicaciones, a medida que comenzamos a hacer esto, ha, en su mayoría, mejorado más allá de algunos errores extraños con algunas cosas tempranas en las que estábamos trabajando. El beneficio es que puedes enviar una respuesta significativamente más rápido y el tiempo para, como, LCP es mejor también. Si estás usando esto para transmitir algo que tarda 20 segundos, no estoy seguro de cuánto le va a gustar eso a Google. Pero si tienes una página que tarda 20 segundos en cargar el contenido, el SEO es el menor de tus problemas. Cierto. Muy cierto. Último aquí. ¿Hay una manera de obtener este beneficio pero reducir la carga en el servidor host? Parece que los componentes transmitidos necesitan ser renderizados en el servidor en cada solicitud. Sí, y eso es increíble. Si lo que más tiempo lleva en tu servidor ahora mismo es la renderización en el servidor, estás trabajando en un proyecto paralelo o has optimizado al máximo tu flujo de datos. De cualquier manera, increíble.

Pero hablando realísticamente, tener que renderizar en el servidor no es una gran penalización cuando piensas en todas las cosas que un servidor tiene que hacer. Antes, teníamos un patrón como este, donde podías obtener todos estos datos de vuelta en una sola solicitud. Tendrías que hacer que el cliente realizara múltiples solicitudes de API. Nunca he visto un mundo en el que un cliente esté solicitando datos que tienen un muro de autenticación donde no solo los está obteniendo más de 15 veces, lo que significa que cada una de esas solicitudes de obtención tiene que ser autenticada de nuevo. Y si esas 15 llamadas de autenticación son de alguna manera mágicamente más baratas que una sola renderización, me encantaría ver el código. Simplemente no es la realidad.

La realidad en la que vivo como desarrollador trabajando en aplicaciones de todos los tamaños es que cuando no puedes enviar todo a través de una sola respuesta, ahora necesitas hacer múltiples solicitudes en esa cascada de solicitudes que siempre costará más en términos de tiempo de ejecución del servidor que si simplemente enviaste lo correcto al usuario desde el principio.

Increíble. Todos, un aplauso para Theo Brown. Gracias a todos.