Componentes del Servidor: La Epopeya de la Representación UX

¡Hola a todos! Hoy hablaré sobre una de las cosas más geniales en las que React ha estado trabajando, que son los componentes del servidor. Nos adentraremos en diferentes conceptos, pero explicaré las cosas de una manera más divertida. Sin más preámbulos, veamos lo que planeamos cubrir en esta charla.

Tal vez estén pensando, ¿qué nos va a contar este tipo? ¿Qué son los componentes del servidor? ¿Cómo funcionan? Bla, bla, bla. Podrían ser mil cosas. Pero para esta charla, quiero mantener el tema de la simplicidad. Así que tendremos solo una agenda en esta charla, que es una breve historia, y trataremos de descubrir las cosas basándonos en esa historia.

Muy bien. Antes de comenzar, un poco sobre mí. Soy Nikhil y trabajo como ingeniero de software aquí en Postman. Normalmente trabajo en cosas muy divertidas como sistemas de diseño y la base general de la experiencia de usuario que hemos establecido aquí en el producto, así que trabajo en los detalles de todas estas cosas. Además, me encanta hablar sobre todo lo que la web está haciendo y hacia dónde se dirige en general. Me gusta hablar sobre el rendimiento y las novedades en el desarrollo front-end. Así que si eres un geek como yo, me encantaría conectarme contigo en Twitter o GitHub. Puedes encontrar todos estos nombres de usuario que definitivamente compartiré con todos ustedes. Realmente me encantaría conectarme con todos ustedes.

Entonces, bueno, ahora vamos a la parte divertida. Comencemos una historia con un chico llamado Bob. Ahora, Bob es una persona que está en la playa y, por accidente, no tiene nada para construir un castillo de arena en la playa. Le encanta construir castillos de arena. Pero lo que tiene que hacer es ver, vale, hay arena y solo necesito usar mis manos, como solíamos hacer en la infancia, ¿verdad? Así que necesitamos, como él, solo necesita construir esto con sus propias manos.

Entonces, la responsabilidad de construir el castillo de arena recae únicamente en Bob. Él tiene que descubrir cómo hacerlo. No tiene nada que le ayude. Ahora, con esta idea inicial de la historia, si te identificas con ella, verás que así es como funciona actualmente la renderización del lado del cliente, ¿verdad? Tendrás un servidor y tendrás a alguien como un cliente que va a solicitar al servidor que haga algo. En este caso, como Bob quiere construir un castillo de arena, tal vez, ya sabes, un cliente quiere construir una página web. Así que lo solicita al servidor. El servidor le dará una respuesta, que son, ya sabes, una lista, como archivos JavaScript, archivos HTML y CSS. Y es responsabilidad del cliente, como Bob, tener toda la arena y saber cómo construir un castillo de arena. Así es como también funciona el navegador. El navegador crea el sitio web final y cuando todo está listo, esto es lo que ves en tu página, ¿verdad? Así que bastante simple.

Ahora pasemos al siguiente paso de la historia. Ahora el siguiente paso sería que Bob recuerda, oh, no tengo nada, así que permíteme pedir ayuda. Así que Bob recibe ayuda de su hermana, Sarah. Ahora, Sarah también está muy apasionada por construir castillos de arena en la playa y está muy bien equipada. Tiene buenos juegos de herramientas, como una pala y una cesta, y puede hacer las cosas de manera rápida y fácil. Así que Bob recibe su ayuda. Ahora, Bob simplemente le da toda la responsabilidad a Sarah y le dice: sí, construye el castillo para mí y lo usaré. Y ahora, si entiendes la analogía, esto es lo que es SSR, ¿verdad? Entonces, SSR o renderización del lado del servidor es cuando le dices al servidor que no quieres hacer las cosas tú mismo, sino que te ayude a construir el sitio web. Así que ahora, cómo difiere en términos de la línea de tiempo es que cada vez que solicito al servidor un sitio web o una página web, el servidor no me está dando los recursos como HTML y CSS. Lo que está haciendo es crear la salida HTML final en el propio servidor. Y obtengo esa salida HTML en el cliente. Ahora, cuando obtengo esa salida HTML, veo algo en la página. Por ejemplo, si hay algo que no tiene JavaScript, pero hay contenido estático como algunas secciones de una página que normalmente no tienen interactividad. Esto es lo mínimo que puedo dar a mis usuarios para que no estén mirando una pantalla en blanco. Y cuando JavaScript está disponible, cuando el cliente solicita el JavaScript después de ver el HTML, ahora puedo hidratar mi aplicación y realmente está lista para que los usuarios interactúen también. Básicamente, esto es lo que hace la renderización del lado del servidor, ¿verdad? Hasta ahora todo bien. Creo que todos conocemos estos conceptos básicos. Ahora quiero desviar esta historia hacia lo que queremos enfocarnos en esta charla. Todos sabemos que hay muchas ventajas y desventajas en cada tipo de paradigma que tenemos aquí. Así que veámoslos uno por uno, muy rápidamente. Si observas, no te voy a contar algunos patrones de estas dos técnicas y cuáles son los pros y los contras en pocas palabras. Entonces, si observas, la renderización del lado del cliente tiene una mejor carga de páginas posteriores, mientras que la renderización del lado del servidor es mejor para la carga inicial de la página, por lo que puede proporcionar contenido más rápido en comparación con la renderización del lado del cliente, porque tiene que preparar todo desde cero y está en el navegador. En segundo lugar, la renderización del lado del cliente hace un buen trabajo después de que se haya completado el trabajo de carga inicial de la página. Si vas a diferentes rutas y tratas de ver diferentes páginas, solo se actualiza el JavaScript que realmente se necesita.

Entonces, como se ahorra mucho volver a cargar porque ya tienes la mayoría de las cosas en tu plato, pero con la renderización del lado del servidor, cada vez que vas a la página o tal vez actualizas la aplicación renderizada en el lado del servidor, tiene que hacer todas estas cosas una y otra vez. Por lo tanto, puede generar altos costos relacionados con el servidor también.

Ahora, las aplicaciones de renderización del lado del cliente son excelentes para crear PWAs, mientras que la renderización del lado del cliente es mejor para la optimización en motores de búsqueda. Y la razón es muy simple porque estás mostrando algo en la página y los rastreadores web o las diferentes API pueden acceder a esa información para mostrarla en los sitios web. Hasta ahora, tenemos este conjunto de ventajas. Y si observas las desventajas, nuevamente, la renderización del lado del cliente no tiene lo que tiene SSR en la carga inicial de la página. Lo que la renderización del lado del cliente tiene es la carga posterior. Tienes que hacer cosas de renderizado y crear las páginas web en el navegador una y otra vez. Y la renderización del lado del cliente nuevamente es mala para el SEO, como ya mencionamos en las ventajas, mientras que SSR es bueno con cosas como el SEO. Entonces, con eso en mente, hagamos esta lista un poco más corta y nos centremos solo en estas dos cosas.

Si ves, una cosa es buena y la otra técnica no lo es, ¿verdad? En este caso, una tiene una buena carga inicial, pero la otra no. Es buena con la carga posterior, las cargas de página. Una es buena con páginas estáticas, por ejemplo, la renderización del lado del servidor, porque si tienes interactividad y JavaScript en eso, nuevamente, llevará más tiempo renderizar tu página en el servidor. Porque nuevamente, JavaScript llevará algo de tiempo. Pero en el caso de la renderización del lado del cliente, es buena con páginas dinámicas, ¿verdad? Porque estás renderizando todo en tu navegador. Hasta ahora todo bien. Es simple. Sabemos que una cosa es buena y la otra no en algunas otras técnicas también. Entonces, no obtienes lo mejor de ambos mundos, ¿verdad?

Ahora, imagina otra parte de la historia, y esto puede ser el clímax de la historia. Digamos que en lugar de que Bob llame a su hermana, sería mejor si Bob tuviera acceso a todas estas herramientas realmente geniales para construir el castillo de arena. Si tuviera acceso a todas ellas, podría elegir cómo obtener ambas ventajas, tener a alguien más que ayude a construir el castillo versus cómo podemos construir esas cosas juntos. Entonces, tal vez pueda combinar ambas ventajas y desventajas con solo un conjunto de herramientas. Y esto es básicamente lo que son los componentes del servidor que el equipo de React ha introducido. Los componentes del servidor son una nueva forma de abstraer tanto la bondad de la renderización del lado del cliente como del lado del servidor, que en realidad, en lugar de darte una página o algo como una salida HTML, como lo hacen ambas técnicas, te brinda un formato de abstracción intermedio que puede ayudar a renderizar las cosas más rápido y te permite elegir qué quieres renderizar en el cliente y qué quieres renderizar en el servidor en la misma página. Intentemos ver cómo los componentes del servidor están cambiando estas cosas, ¿verdad? Entonces, veamos nuevamente un diagrama muy simple de un cliente y un servidor. Ahora, el cliente solicita una página web. Lo siento, el servidor está haciendo parte de la renderización del lado del servidor. En realidad, está renderizando tus componentes del servidor en el servidor. Y ahora, en lugar de darte esta salida, no te da tu HTML o la renderización del lado del servidor, alguna salida.

que puedes mostrar directamente en el navegador. Te proporciona un formato especial de datos, algo así como JSON, o como un formato muy extraño, pero te brinda un formato especial de data. Ahora, esto no es para ti. Esto es para que React descubra cómo puede renderizar estos componentes más rápido y fusionar todos los cambios que ha realizado en el cliente, fusionarlos de nuevo en su árbol de DOM virtual, ¿verdad? Entonces, esta es la forma más simple en que puedes poner esto. Por lo tanto, renderiza algunas partes de tu página que son componentes del servidor. Los renderiza en el servidor. Te proporciona algunos data y finalmente genera, como tu, tu, tu cliente realmente va a hacer el resto de las cosas. No es tan pesado, pero puede hacer esa parte mucho más rápido que la renderización del lado del cliente. Muy bien. Entonces, hablar de los pros y los contras de todo esto es lo que obtienes básicamente de esta técnica, de todo esto FSR. Entonces, una cosa es que obtienes un tamaño de paquete cero y tienes razón cuando escuchas eso. Entonces, los componentes del servidor se ejecutan solo en el servidor. Por lo tanto, nunca envías el JavaScript que se ha ejecutado en el servidor. Por lo tanto, ninguno de los componentes, tal vez miles o cientos de componentes, ninguno de ellos se envía realmente al cliente, lo que es exactamente un tamaño de paquete cero, como también has estado viendo en este ejemplo, Dan Avermoff también lo mostró en una de las charlas. Entonces, este es uno de los mayores pros. Ayuda a que el paquete del lado del cliente sea mucho más pequeño. Y como he estado diciendo todo este tiempo, obtienes lo mejor de ambos mundos, que son estrategias tanto del lado del cliente como del lado del servidor combinadas en una técnica. Entonces, imagina algo así. Tienes un árbol de DOM. Puedes tener algo que se está renderizando en el servidor. Hay algo que se está renderizando en el lado del cliente. Hablaremos sobre las implementaciones, cómo puedes hacer eso. Pero ahora puedes indicarle a React que algunas partes de mi aplicación web deben ser renderizadas en el servidor. Y en la misma página, algunas de ellas deben ser renderizadas en el lado del cliente. Entonces, ahora puedes darle esa indicación a React. Lo cual no estaba presente en la renderización del lado del servidor, y ahora React se encargará del resto de las partes en las que trabajar en el servidor y qué simplemente omitir y dejar que el cliente se encargue. Esto es algo muy mágico y muy poderoso para hacer. Muy bien. Pasando a la siguiente cosa, la fragmentación automática de código. Personalmente, me gusta esto porque, ya sabes, actualmente tendrías que escribir un código que sea algo como esto. Tienes una biblioteca simple de React.lazy y puedes cargar de forma diferida tus componentes como o

los necesitas, ¿verdad? Entonces tienes que escribir algunas cosas. Entonces, con los componentes del servidor, esas APIs React.lazy, desaparecen porque ellos se encargan de esto por ti. Ahora, si ves en este ejemplo, como solo iré a la diapositiva anterior y te lo mostraré. Entonces tenías el antiguo renderizador de fotos y el nuevo renderizador de fotos, estos dos componentes, que eran como componentes del cliente, y los cargabas de forma diferida. Pero ahora, como todo se está renderizando en el servidor, los componentes del servidor en el servidor, pueden realmente separar todos los importaciones del cliente, que no se están utilizando mientras se renderiza tu componente del servidor final, eso puede componer tu cliente y el servidor. Entonces, en realidad, puede hacer esa fragmentación automática de código por ti. Por ejemplo, en este caso, si las banderas de características como el nuevo uso del renderizador de fotos es verdadero, solo se cargará el nuevo componente del renderizador de fotos como parte del JavaScript aquí y no el otro. Muy bien. Pasando al siguiente paso, si te gusta imaginar este escenario, tienes tus componentes que antes estaban en tu cliente, pero ahora hemos trasladado estos mismos componentes de React del lado del cliente al servidor. Entonces, como estamos muy cerca del servidor, ahora podemos tener llamadas más rápidas y directas con el servidor y la respuesta que podemos obtener de la base de datos, puede ser mucho más rápida, diría yo, en comparación con las llamadas fetch habituales que hacemos. Entonces, es súper rápido que eso. Muy bien. Hay algunas cosas que tampoco podemos hacer, que es con, aunque puedes usar componentes del cliente y del servidor, ambos en conjunto en el servidor, cosas como estados y efectos, que suelen ser cosas de los componentes del cliente. Los componentes del servidor no admiten eso. Entonces, estas cosas son algo que no puedes usar. Son algo muy bueno. Si quieres imaginar algo, los componentes del servidor se utilizan generalmente para mostrar algunos data o hacer algunas llamadas fetch o hacer algún tipo de obtención de data. Cuando hay interactividad involucrada, debes usar componentes del cliente. Entonces, solo quiero decir que hay una regla básica, obtención de data o mostrar cosas sin interactividad, componentes del servidor; interactividad y mayor riqueza, debes usar eso es cómo debemos separar esos dos. Lo siguiente que debes hacer, si te gusta puedes tener componentes del servidor y también puedes renderizar un componente del servidor dentro de un componente del servidor o puedes renderizar un componente del cliente dentro de él. Pero solo puedes también pasar props desde componentes del servidor a componentes del cliente, pero solo las props que son serializables a través de la red, porque los componentes del servidor no se renderizan en el servidor. Como que van a, lo siento, los componentes del servidor se renderizan en el servidor y los componentes del cliente no. Entonces, tienes que, si quieres compartir data entre ellos, tienen que pasar por el enlace del servidor. Entonces, solo los datos serializables, como, ya sabes, objetos y cadenas, números, cosas así. Se pueden serializar fácilmente. Pero cosas como, ya sabes, funciones, no puedes, no puedes usarlas como, no puedes pasarlas como una prop. Entonces, esta es una limitación. Entonces, bueno, ahora, sí, ahora veamos cómo usar realmente los componentes del servidor. ¿Qué necesitas hacer para comenzar? En React, creo que muchos de nosotros ya hemos visto la charla de cómo el equipo de React lo había estado demostrando. Pero, como ejemplo que React había mencionado, cómo crear un componente del servidor. Entonces, esta es una indicación de que este componente se renderizará como un componente del servidor en el servidor.

Next.js lo hace de una manera diferente. Te dice que todo lo que crees dentro del directorio de la aplicación será un componente del servidor de forma predeterminada. Aunque también puedes hacer algunos ajustes, es posible que te preguntes cómo crear un componente del cliente si quieres crear un componente del servidor. ¿Cómo elijo entre los dos? Solo necesitas agregar una línea, que es la directiva 'use client'. Esto le dirá a React que esto no es nada. No se renderizará en el servidor, por favor, renderízalo en el cliente.

Y así es como hace esa distinción. Muy bien, suficiente charla. Vamos ahora a la demostración y veamos cómo están las cosas. Ahora he abierto esta demostración muy pequeña aquí como una página separada. Y esto te muestra algo muy simple. Es solo una llamada a la API que hago en cada recarga, y solo te muestra una broma de desarrollador. Como una pregunta, y luego te da una respuesta o una línea final. Como en este caso, ¿por qué los programadores de nivel de ensamblador necesitan saber nadar? Porque trabajan por debajo del nivel del mar. Buena. OK. Así es como es la demostración básica. Entonces, si ves las desventajas en las que hemos estado pensando sobre la representación en el lado del cliente y en el lado del servidor. Entonces, la representación en el lado del cliente en realidad representa las cosas por adelantado cuando obtiene los datos. Entonces, cómo puedes probarlo es si actualizo mi aplicación aquí, veré que hay algunos datos estáticos que puedo obtener como parte de HTML, pero como JavaScript no se va a cargar, es posible que no obtenga todo esto. Que es como la pregunta y la respuesta que estoy obteniendo como una llamada a la API. Entonces, si actualizo, verás que por un tiempo, no obtengo la pregunta y la respuesta. Solo obtengo el contenido estático que he codificado porque así es como funciona la representación en el lado del cliente, ¿verdad? Todavía está obteniendo datos del servidor y cuando está allí el JavaScript, va a representar las cosas. Va a construir el castillo de arena de antemano. Así es como sucede esto. Ustedes ya saben cómo se comportará la representación en el lado del servidor en este caso, ¿no? Ahora estamos preparando todo en el servidor. No estamos esperando, no estamos haciendo eso en el cliente. Entonces, si ahora actualizo esta página, no debería ver un área en blanco, debería ver esto de antemano. Entonces, si actualizo, verás, oh, okay, tal vez creo que voy a reiniciar. OK, algo con la versión anterior, no sé. OK, veamos si esto se reinicia. OK, sí, aquí estamos. Entonces, si intento actualizar, verás, veo los datos, como veo todo de antemano, no estoy esperando una pantalla en blanco o que mi JavaScript se ejecute en este cliente o algo así, estoy preparando todo en el servidor, enviándolo. Así es como están sucediendo las cosas. Muy bien, ahora, cómo son diferentes los componentes del servidor con esto. Ahora veamos algunas cosas muy interesantes ahora.

De acuerdo, abramos nuestras antiquísimas DevTools. Y veamos qué es lo que realmente se está enviando. ¿Cómo funciona en realidad? Ahora, si actualizo esta página, verás que sigo obteniendo los datos porque en realidad se están preparando para mí como una aplicación renderizada en el lado del servidor. ¿Correcto? Y si intento ver qué es lo que realmente se está enviando. Vamos a la. Sí. Esto es lo que realmente se está enviando ahora. Es una especie de conjunto extraño de cosas que se están utilizando, pero es un canal de comunicación intermedio entre el servidor y el React en el cliente para decirte cómo fusionar todas estas cosas que se renderizan en el servidor en el cliente, de modo que el cliente tenga que hacer un trabajo mínimo. Esto es lo que realmente se está enviando. ¿Correcto? Ahora intentemos ver y creo que tengo otro ejemplo para explicarlo. Ya hemos hablado de cómo se pueden utilizar componentes del cliente y varios componentes en conjunto en el servidor. ¿Correcto? Si ves, tengo un componente hijo, un componente del cliente como hijo que no estoy renderizando en el servidor y dentro de él estoy renderizando un componente del servidor. ¿Correcto? Idealmente, desde el punto de vista teórico, podríamos decir que el componente del servidor no debería enviar nada al cliente. Por lo tanto, no debería ver nada en mi trabajo. Pero, ¿qué está compilando webpack? Pero podría ver algo en el cliente. Pero, ¿necesito esta línea de componente hijo? Vamos a fuentes, vamos a webpack. Sí. Si ves, había una aplicación y solo tiene un archivo .psx de cliente que es solo para el componente del cliente, que agregamos todo esto en el servidor, pero react solo lo envía al navegador para que lo renderice como un componente del cliente, pero no ves ningún código que se envíe para el componente del servidor. Por lo tanto, el tamaño del paquete es absolutamente cero, no se envía nada como parte de tu trabajo establecido para el componente del servidor, pero el componente del cliente te lo proporciona. Por lo tanto, es muy personalizable. De acuerdo, esto fue una cosa. Sí, creo que he cubierto la mayor parte de esto. Sí, esto es en realidad el poder de los componentes del servidor. Te permite personalizar básicamente lo que quieres renderizar en el cliente, lo que quieres renderizar en el servidor y no hacer todas las cosas como

Una y otra vez. Así que obtienes como nuevamente como de qué estás hablando. Lo mejor de ambos mundos es lo que hace que la estrategia sea tan hermosa. Bueno, con eso dicho. Ahora hablemos de algunas cosas más. Es posible que estés pensando que los componentes del servidor son tan geniales que puedes usarlos en cualquier lugar, en cualquier momento y que tus sitios web funcionarán súper bien, pero todo tiene un inconveniente. Entonces, nuevamente, esta estrategia también tiene sus desventajas, pero lo más importante que discutimos es que puedes usar efectos o actualizaciones de estado, pero aún necesitas un servidor, por lo que puede afectar los costos relacionados con el servidor. Pero lo más importante, no recomendaría probarlos en las aplicaciones de producción en sí, porque el estado actual es que el equipo de React está haciendo un trabajo absolutamente excelente al recopilar comentarios y ser muy transparente sobre sus hallazgos e investigaciones, pero aún se encuentra en la etapa experimental en React, y si quieres probarlo, puedes comenzar con NextJS, así es como construí esta demostración en sí. Es muy fácil de usar, realmente me encantaría que lo intentaras. Un par de cosas, si quieres profundizar en esto, realmente recomendaría ver este video de YouTube del equipo de React, donde realmente te lo demuestran y explican el problema con más detalles y también lo explican con una demostración muy genial, así que realmente me encantaría que lo intentaras, y también hay una documentación genial que personalmente encontré muy útil y que es muy fácil de entender, por ejemplo, la documentación oficial de Next.js y también hay un artículo muy interesante de Zenstack sobre los componentes del servidor y cómo puedes comenzar a usarlos más rápido, así que definitivamente lo recomendaría aquí. Bien. El código de esta demostración lo puedes encontrar en la URL de slackbits, así que siéntete libre de jugar con él, intentar romperlo, hacer lo que quieras con él, siempre es divertido aprender de esta manera, y si ves algún problema, no dudes en mencionarme en Twitter u otros canales. Y una de las últimas cosas es que estos son algunos problemas y espacios de problemas interesantes similares con los que seguimos trabajando en Postman. También estamos contratando, así que si quieres formar parte de este viaje, no dudes en visitar el sitio web de carreras y conectarte. Eso es principalmente lo que quería discutir. Espero que estén disfrutando de los increíbles conjuntos de conferencias y charlas que tenemos en el evento. Sigan aprendiendo, disfrutando y nos vemos nuevamente.