GraphQL en el Mundo de React Server Components

Bienvenidos a todos a React Advanced 2024. Mi nombre es Gerald Miller, y soy un ingeniero de software principal en Apollo trabajando como mantenedor a tiempo completo en Apollo Client. Y hola a todos, mi nombre es Alessia Bellisario, y soy ingeniera de software en Apollo también trabajando en Apollo Client.

Y pensé que comenzaríamos retrocediendo en el tiempo al React Advanced London del año pasado en 2023, cuando Gerald y yo dimos una charla llamada Cómo Usar Suspense y GraphQL con Apollo para Construir Grandes Experiencias de Usuario. Ahora, en ese momento, los componentes del servidor de React estaban en la mente de todos, pero discutirlos era un objetivo explícito no de nuestra charla que mostró cómo usar suspense efectivamente con Apollo Client. Y solo quiero señalar, siéntanse libres de volver y usar el código QR en esta diapositiva para buscarlo si quieren verlo más tarde.

Entonces, aunque no nos centramos en RSE el año pasado, este año nos gustaría presentarles GraphQL en un mundo de componentes del servidor. Hablemos sobre cómo y por qué podrían combinar estas tecnologías y qué permite esta pila. Para comenzar, plantearemos la pregunta que teníamos en mente cuando vislumbramos por primera vez el nuevo paradigma de los componentes del servidor. Honestamente nos preguntamos lo mismo cuando nos propusimos proporcionar alguna compatibilidad con los componentes del servidor y Apollo Client. Y después de un año, podemos decir con confianza que sí, GraphQL tiene un lugar en un mundo de componentes del servidor. Muchas gracias por venir a nuestra charla. Eso será todo por hoy.

serio, nos ha sorprendido gratamente cuánto se ha adoptado GraphQL combinado con componentes del servidor en el último año. Y eso se refleja en esta línea de tendencia y en este gráfico de descargas de NPM que vemos aquí. Esta línea de tendencia ha continuado en esta trayectoria ascendente desde realmente desde el primer día, ya que hemos visto más y más equipos usando esta tecnología y usándola en producción con excelentes resultados. Así que claramente hay algo aquí. Y esta es una evidencia temprana de que a los ingenieros les encanta construir con estas tecnologías.

Sí, pero puede que notes si miras esa captura de pantalla que hemos lanzado esto bajo un nombre de paquete diferente, podrías estar preguntando, ¿por qué hay necesidad de un paquete separado? ¿Por qué no simplemente construir todo esto en Apollo Client Core? Y realmente, la respuesta es porque al trabajar con RSC, hay algunas cosas diferentes que necesitamos tener en cuenta y solo algunos paradigmas que necesitamos seguir. Así que, por ejemplo, en los componentes del servidor, es una mejor práctica que crees tus instancias de cliente una vez por solicitud. Y la razón de esto es porque no quieres múltiples solicitudes entre múltiples usuarios compartan una caché donde podrías tener datos mezclándose y combinándose. Eso puede resultar en datos filtrados entre tus usuarios y podría resultar en algunas implicaciones de seguridad. Así que proporcionamos algunas de las utilidades para asegurarnos de que eso suceda correctamente. Y en el extremo del componente del cliente, los datos que obtenemos en los componentes del cliente se transmiten desde el servidor al navegador y se utilizan para hidratar la caché en el extremo del navegador. Y esto realmente ayuda a evitar las solicitudes en el propio navegador ya que ya estamos haciendo el trabajo en el servidor. Si tienes mucha curiosidad por profundizar en más detalles, porque no vamos a cubrir demasiado de lo que está sucediendo explícitamente, te animaría a que eches un vistazo a la charla de Lenza de React Advanced del año pasado que profundiza un poco más en más de los detalles específicos de esta biblioteca.

Bien, así que pongamos la mesa aquí y hablemos de qué son los componentes del servidor y respondamos esa pregunta. Ahora, hay tantos excelentes introducciones sobre los componentes del servidor de React por ahí, incluyendo el blog de Josh Como, Making Sense of React server components, del cual tomamos la idea para estos diagramas. Y he enlazado ese blog usando el código QR en la esquina. Y definitivamente deberías echarle un vistazo. Echa un vistazo al post de Josh si te gustaría leer más. Pero aquí vemos el ciclo de vida de una solicitud típica hecha a una aplicación, una aplicación de React que está usando renderización del lado del cliente. Así que cuando llega una solicitud del cliente, el servidor o incluso un CDN responderá con un documento HTML que contiene una etiqueta de script que le dice al navegador dónde obtener el paquete de JavaScript necesario para renderizar tu aplicación. Y este paquete contiene tu código de aplicación y también todo el código de biblioteca que tu aplicación necesita para renderizar cualquier cosa en la pantalla. Así que una vez que vemos que hemos descargado el JavaScript y el navegador ha analizado ese JavaScript, tu código de aplicación puede comenzar a ejecutarse. Y es entonces cuando cualquier obtención de datos que se haga durante la renderización puede realmente comenzar. Así que esto podría ser una llamada fetch a una API que ejecuta una consulta de base de datos, por ejemplo. Es solo cuando esa solicitud regresa con datos que tu aplicación puede renderizar contenido en la pantalla. Así que puedes imaginar los spinners que un usuario podría ver aquí. Ahora, con la renderización del lado del servidor, tu aplicación de React puede realizar su renderización inicial en el servidor, lo cual es una buena optimización. Tal vez esto sea solo la estructura de la aplicación, o tal vez si estás usando un meta framework como Next.js, la renderización inicial del servidor también puede incluir algunos datos obtenidos en el servidor que se inyectan a través de props para ese pase de renderización inicial del servidor. Pero en general, la mayoría de los datos se obtendrán en navegaciones posteriores en el navegador después de la hidratación que vemos en el cliente, en cuyo punto tenemos la misma necesidad de atravesar esa frontera cliente-servidor cuando hacemos una obtención de cliente para algunos datos que necesitamos del servidor. Y vale la pena señalar aquí que Apollo Client también proporciona APIs para inicializar tu caché en el servidor y realizar esa renderización inicial del servidor.

Así que esta es una técnica y enfoque bien probados. Pero con React Server Components, React introdujo un nuevo primitivo, y ese es este nuevo componente del servidor que solo se renderiza una vez en el servidor. Así que sus dependencias están garantizadas para nunca terminar en tu paquete de cliente y puedes ejecutar código solo del servidor, como conectarte directamente a una base de datos que vemos aquí.

También vale la pena mencionar que bajo este modelo, los componentes del cliente es un poco un nombre inapropiado, ya que los componentes del cliente también se renderizan en el servidor durante un pase inicial de renderización del lado del servidor. Pero podrías preguntarte, ya que estamos hablando mucho de bases de datos, ¿dónde encaja GraphQL realmente en nuestra arquitectura general de la aplicación? Así que podemos echar un vistazo a este diagrama aquí, y realmente esto empiezas a ver esto como cuando tu producto en tu organización comienza a crecer.

Así que tu arquitectura puede comenzar a evolucionar y parecerse más a algo como esto, donde tu servicio realmente comienza a dividirse entre muchos servicios diferentes y creando una arquitectura de microservicios. Así que podrías dividir tus servicios por función o por equipo. Pero realmente el punto aquí es que es posible que ya no estés hablando directamente con una base de datos. Y aquí es donde GraphQL realmente brilla porque puede crear esa capa unificadora entre todos tus microservicios y darte una API unificada con la que tus clientes pueden hablar. Así que en este caso, nuestra aplicación de React Server Component hablará directamente con nuestra API de GraphQL para obtener sus datos. Así que volvamos a nuestra visualización de nuestra solicitud de React Server Component aquí y una solicitud de cliente a servidor donde ahora podemos reemplazar esa consulta de base de datos con una consulta de GraphQL. Y aquí, si ampliamos un poco más, podemos ver en esta área de renderización del servidor de nuestro diagrama, tenemos tanto los React Server Components como componentes del cliente que hacen una renderización inicial durante ese pase SSR en el servidor.

Así que voy a ampliar un poco y echar un vistazo a la obtención de datos en los componentes del servidor usando Apollo Client. Así que echemos un vistazo a algún código aquí. Primero vamos a importar esta función register Apollo Client junto con Apollo Client in-memory cache de nuestro paquete de soporte de Next.js app. Usando la función register Apollo Client, requerimos que crees tu instancia de Apollo Client en el callback de esa función. Así que como mencioné antes, una de las razones por las que necesitábamos ese paquete adicional es porque queremos asegurarnos de que nuestro cliente esté limitado a una sola solicitud. De esa manera, nuestra caché no se comparte entre múltiples solicitudes, es decir, potencialmente múltiples usuarios. De lo contrario, podríamos arriesgarnos a filtrar datos de usuario. Así que esa función register Apollo Client devuelve una función auxiliar llamada getClient que cuando se llama, devuelve nuestra instancia de Apollo Client limitada a esa solicitud. Así que podemos usar esto para obtener datos en nuestros componentes del servidor.

Así que echemos un vistazo a un componente del servidor y usando esta función getClient. Así que aquí tenemos nuestro componente del servidor asincrónico. Y como estamos en el componente del servidor, podemos simplemente usar la palabra clave await directamente y esperar nuestra solicitud aquí. La mayor diferencia entre el paquete principal de Apollo Client y nuestro paquete de aplicación es realmente ese uso de esa función getClient para obtener acceso a nuestra instancia de cliente, en la cual podemos llamar a query en ella. Luego podemos usar los datos devueltos directamente por esa solicitud para renderizar el resto de nuestro componente del servidor. Solo quiero señalar algunas mejores prácticas al trabajar con componentes del servidor. ¿Qué deberíamos poner aquí frente a los datos obtenidos en los componentes del cliente? Idealmente, quieres poner datos aquí que rara vez cambian y realmente no quieres superponer datos en tus componentes del servidor con datos obtenidos en los componentes del cliente. Los componentes del cliente están realmente destinados a la interactividad, lo que significa que la caché y los datos en esa caché cambian con el tiempo.

Si tienes datos que se superponen entre los dos, es muy fácil que esos datos crezcan fuera de sincronización entre sí y estén desactualizados. Las cachés no se comparten entre tus componentes del servidor y tus componentes del cliente. Así que realmente quieres asegurarte de que esos datos estén separados tanto como sea posible.

Gracias, Gerald. Ahora, echemos un vistazo más de cerca a la obtención de datos en componentes del cliente. Y aquí hay un ejemplo de un componente del cliente donde podemos instanciar nuestra instancia de Apollo Client y también configurar nuestro proveedor de Apollo Client. Y lo que puedes notar aquí es que en la parte superior, tenemos nuestra directiva use client para indicar que ahora estamos entrando en ese límite del componente del cliente. Y estamos importando Apollo Next app provider, Apollo Client y in-memory cache de nuestro paquete de soporte experimental de Next.js app en lugar de Apollo Client. Y también requerimos que crees una función make client que cree una nueva instancia del cliente y pases esa función a Apollo Next app provider. Y recuerda que el contexto de React no se puede usar en componentes del servidor. Por eso tenemos que realizar esta configuración en un componente del cliente. Pero de lo contrario, mucho de esto se verá bastante familiar para los usuarios de Apollo Client.

Y echemos un vistazo a cómo realmente obtendríamos datos en un componente del cliente. Así que aquí podemos ver nuevamente con use client, estamos en un componente del cliente aquí donde ejecutaremos esta consulta all products y obtendremos una lista de productos de nuestra API de GraphQL. Y podemos importar use suspense query directamente de Apollo Client como normalmente lo haríamos para usar este hook de obtención de datos habilitado para suspense para ejecutar nuestra consulta en nuestro componente del cliente. Y lo increíble de esto es que esta solicitud de obtención se iniciará durante ese pase SSR y los datos se transmitirán al navegador donde finalmente se renderizarán.

Así que para revisar algunas mejores prácticas para componentes del cliente aquí, es realmente el inverso de lo que Gerald habló sobre los componentes del servidor. Así que aquí queremos obtener y consumir datos que puedan cambiar como resultado de mutaciones e interacciones del usuario. Y así es como nuestra aplicación realmente podrá beneficiarse de nuestra caché normalizada en Apollo Client y podremos volver a renderizar y reaccionar a las actualizaciones de la caché a medida que ocurren en el cliente. Y así, nuevamente, cuando estructuras tus consultas, aquí es donde no queremos tener datos superpuestos obtenidos entre nuestros componentes del servidor y del cliente porque, nuevamente, no queremos que se desincronicen. Así que si ampliamos nuevamente en esa renderización del servidor, notarás que nuestros componentes del servidor realmente renderizan y comienzan a obtener antes que nuestros componentes del cliente. Pero como sabemos, uno de los grandes principios del rendimiento en las aplicaciones de React es iniciar tu obtención lo antes posible. Así que sería realmente bueno si pudiéramos iniciar nuestra obtención en nuestros componentes del servidor, pero aún así renderizar esos datos en nuestros componentes del cliente. Así que realmente podemos hacer esto dentro de Apollo Client en nuestros componentes del servidor usando una utilidad adicional devuelta por esa función register Apollo Client. Y esto nos devuelve un componente preload query que podemos usar para hacer exactamente esto. Así que echemos un vistazo a nuestro ejemplo aquí. Podemos usar esto en nuestros componentes del servidor envolviendo nuestros componentes del cliente como hijos. Así que en la parte superior, verás nuestro componente app aquí donde nuestro componente preload query envuelve nuestro componente all products, y ese componente all products es nuestro componente del cliente en este ejemplo. Algo a destacar aquí es que notarás que la consulta pasada a preload query y a use suspense query es la misma consulta. Y eso es porque queremos asegurarnos de que la solicitud se comparta entre los dos.

Así que también debería mencionar que tenemos otra forma de leer datos de la consulta, pero te animaría a que consultes la documentación para eso porque no vamos a ver eso demasiado hoy. En términos de mejores prácticas y uso de esto, solo quiero señalar un par de prácticas aquí. No querrás usar consultas arbitrarias y preload query, porque, nuevamente, el punto de hacer esto es poder compartir esa solicitud entre tu componente del servidor y tu componente del cliente. Así que esas consultas están destinadas a ser compartidas entre sí. Y al igual que los componentes del cliente, no queremos superponer datos renderizados por un componente del servidor. Así que, sí, es obtenido por un componente del servidor, pero como es renderizado por un componente del cliente, se aplica el mismo principio. Es realmente fácil que tu caché y los datos se desincronicen si estás renderizando esos datos en ambos. Así que solo asegúrate de que los datos obtenidos por preload query estén realmente destinados a tu interactividad y esos componentes del cliente.

Bien. Ahora, tomemos algunos de esos conceptos y veamos cómo se aplican en una aplicación. Así que aquí hay una experiencia que podríamos tener en nuestra app. Ahora en este wireframe, los cuadros verdes representan componentes del servidor que están renderizando datos que rara vez cambian. Y nuestro contenido más interactivo es renderizado por un componente del cliente, que eventualmente se carga. Pero, ¿qué sucede cuando la consulta que nuestro componente del cliente está haciendo tarda un tiempo? Veamos este ejemplo nuevamente, pero con tiempo real aquí. Así que eso tomó tres segundos para que esa consulta se resolviera y los datos se transmitieran a nuestros componentes del cliente que finalmente lo renderizaron.

Y esta es la consulta GraphQL que respalda esta UI. Así que en nuestra consulta all products, estamos obteniendo una lista de productos y todos estos campos, el ID, el título, la URL de los medios para mostrar esa imagen y una lista de reviews que contienen calificaciones de productos. Y a través de alguna telemetría, hemos identificado que las reviews son el campo más lento en nuestra consulta. Y nuevamente, esta es una de las fortalezas de GraphQL en que te permite hacer una única solicitud de red para todas las necesidades de datos de tu UI. Pero la contrapartida de eso es que tu consulta será tan lenta como sus campos más lentos. Y así aquí sabemos que podríamos renderizar el resto de la información de nuestro producto mucho antes, pero tenemos estas reviews que nos están retrasando. Entonces, ¿podemos hacerlo mejor aquí?

Y luego dejaremos que nuestras reviews se transmitan más tarde. Y así sabemos que React proporciona una forma de marcar partes de nuestro subárbol con estados de carga al agregar límites de suspense adicionales. Pero eso también significa que necesitamos que esos componentes se suspendan. Entonces, ¿qué podríamos hacer aquí realmente? Idealmente, nos gustaría mantenernos con una sola solicitud de red para que podamos evitar, en este caso, un problema de consulta de n más uno. Realmente no queremos ejecutar búsquedas adicionales para esas reviews para cada uno de esos productos. Así que echemos un vistazo a lo que GraphQL podría hacer para ayudarnos aquí.

Así que echemos un vistazo a lo que GraphQL podría hacer para ayudarnos aquí. Primero, vamos a profundizar un poco en los fragments y hablar sobre qué son. Para aquellos que no están familiarizados con GraphQL, los fragments, los fragments son esencialmente unidades reutilizables y son un subconjunto de campos que nos permiten dividir los datos complicados de nuestra aplicación en partes más pequeñas. Esto puede ser realmente útil si deseas combinar muchos componentes de UI juntos en una única obtención de datos donde cada uno de esos fragments define los requisitos de datos para un componente.

Y así es como se ve sintácticamente. En la parte inferior, ves nuestra definición de fragment, que incluye los campos que queremos incluir como parte de ese fragment. En este caso, es ese campo de reviews que ves allí. Podemos incluir ese fragment en nuestra consulta usando esa sintaxis de spread que ves arriba. Esto solo asegura que los campos en ese fragment se obtengan como parte de nuestra consulta.

Y aquí es cómo esa consulta y el fragment que contiene pueden mapearse a los componentes que estamos renderizando. Aquí podemos ver el título y la URL de los medios donde se renderizan y las reviews que se renderizan debajo. Y nuevamente, al punto que Gerald hizo sobre cómo los fragments pueden permitirte delimitar esas necesidades de datos de un componente específico. Aquí es donde veremos nuestro componente de reviews de productos que está renderizando las estrellas. Simplemente declarando ese requisito de datos a través del uso de un fragment y el hook use fragment de Apollo client.

Así que, ya sabes, en este caso, todos los productos se renderizan debajo y todas las reviews se renderizan debajo. Así que, ya sabes, en este caso, todos los productos están obteniendo todos los datos que esta UI necesita. Pero las reviews de productos están renderizando los datos de reviews usando ese hook use fragment. Y vale la pena señalar que los fragments no son suficientes por sí solos para mejorar la experiencia del usuario aquí, porque aunque nos dan una forma de incluir las reviews de productos, los datos de los componentes de reviews de productos en nuestra consulta, todavía estamos esperando que todos los campos se resuelvan antes de poder renderizar nuestra página. Así que vamos a recurrir a otra cosa que GraphQL nos da aquí para resolver este problema, y eso es la directiva defer.

¿Qué es la directiva defer? Defer nos permite marcar un conjunto de campos como diferidos dentro de nuestra consulta. Todavía obtenemos el beneficio de una única solicitud de red, pero defer le dice a nuestro servidor GraphQL que transmita esos campos diferidos más tarde a través de una respuesta de múltiples partes. Y esto nos da la capacidad de transmitir datos de manera incremental. Esto realmente puede proporcionar una gran experiencia para situaciones donde algunos campos tardan mucho más en resolverse que otros. Y así es como se ve en nuestra consulta. Esencialmente nos permite anotar ese fragment de campos de producto con una directiva defer para indicar que todos los campos dentro de campos de producto pueden transmitirse en un momento posterior.

Así que hemos aprendido sobre estas utilidades, pero ¿cómo las usamos realmente en nuestra aplicación? Así que vamos a hacerlo y vamos a recorrer una demostración de esto en acción. Solo quiero señalar antes de avanzar demasiado que lo que estamos a punto de mostrarles aquí es altamente experimental. Aún no se ha lanzado en Apollo Client, pero estamos trabajando en esta funcionalidad y queremos agregarla a una versión futura. Así que solo queríamos poder emocionarnos sobre el futuro con ustedes sobre las posibilidades que usar GraphQL en la arquitectura de componentes del servidor de React proporciona. Así que vamos a profundizar.

Sabemos que podemos proporcionar fallbacks adicionales y spinners como estados de carga en nuestros componentes de React añadiendo límites de suspense a nuestros componentes. Así que vamos a empezar añadiendo un límite de suspense alrededor de nuestro componente de reseñas de productos porque lo que realmente queremos es que ese componente de reseñas de productos se suspenda para que podamos mostrar algunos de esos detalles sobre el producto lo antes posible antes de que esas reseñas se transmitan más tarde.

Echando un vistazo a nuestro componente de reseñas de productos, nuevamente, queremos que esto se suspenda. Así que vamos a reemplazar useFragment con el hook useSuspenseFragment. Y esto simplemente nos proporciona la capacidad de dar un fragmento habilitado para suspense donde si ese fragmento aún no se ha cargado, nos suspenderemos hasta que lo esté. Y finalmente, queremos volver a nuestra consulta y anotar nuestro fragmento con esa directiva diferida para que podamos indicarle que se transmita más tarde.

Así que veamos realmente una demostración de esto en acción y cómo estos cambios pueden funcionar con nuestra aplicación. Así que esta demostración aquí junta todas estas piezas. Aquí vemos una aplicación de Next.js usando componentes de servidor de React y el directorio de la aplicación que comienza obteniendo nuestra consulta en el servidor en nuestro componente de servidor usando preload query. Y esa consulta contiene la directiva diferida en nuestros campos de calificaciones. Y el componente de calificaciones aquí es capaz de suspender en el cliente hasta que ese fragmento sea transmitido al navegador. Así que aquí vemos lo mejor de los componentes de servidor de React y lo mejor de GraphQL combinados y algunas de las cosas que se vuelven posibles. Podemos mantener la única obtención que GraphQL nos da, pero con el poder de suspense y defer, esa respuesta de múltiples partes puede realmente ser transmitida a través de ese límite de servidor cliente que permite algunas experiencias de usuario bastante sorprendentes.

Así que, ¿qué escuchamos hoy? Hoy, hablamos sobre cómo el paquete Next.js de Apollo te da mecanismos para primero obtener datos directamente en componentes de servidor de React para ser renderizados por componentes de servidor, pero también una forma de precargar con preload query para que puedas comenzar a obtener datos en RSC que pueden ser renderizados en componentes de cliente. Y también, puedes usar los hooks de obtención de datos habilitados para suspense de Apollo Client directamente en tus componentes de cliente donde esa obtención será realmente iniciada en el servidor y los datos serán transmitidos al navegador donde se renderizan. Y finalmente, próximamente, podrás usar fragmentos habilitados para suspense y transmitir y renderizar fragmentos de múltiples partes al navegador. Y finalmente, también estamos trabajando en el soporte de otros meta marcos construidos sobre RSC. Así que con todo eso dicho, eso es todo lo que tenemos hoy. Muchas gracias. Gracias a todos.