Diseño de esquema GraphQL a prueba de futuro

Hola a todos. Hoy vamos a hablar sobre cómo construir excelentes experiencias de servidor GraphQL con GraphQL Yoga versión 3.

En primer lugar, soy Loren y soy un desarrollador de código abierto en The Guild. Puedes encontrarme en Twitter y GitHub, donde principalmente publico sobre desarrollo de código abierto.

Antes de comenzar con la charla en sí, hablemos un poco sobre The Guild. Somos un grupo de desarrolladores que hemos estado trabajando en código abierto desde hace mucho tiempo y nos reunimos para trabajar en proyectos de clientes. Básicamente, trabajamos con los clientes para resolver sus problemas y luego compartimos esas soluciones con el mundo a través del código abierto.

Aquí tienes un resumen breve de algunos de nuestros proyectos más destacados en este momento. Tenemos el generador de código, que es una herramienta para generar código y definiciones de tipos para cualquier lenguaje en tu servidor GraphQL existente. También tenemos GraphQL mash, que es una biblioteca para convertir cualquier fuente de datos en un SDK o gateway GraphQL. Tenemos el inspector de GraphQL, que es una herramienta de validación de esquema y detección de cambios para el flujo de CI/CD. También tenemos GraphQL Hive, que es un registro de esquema y plataforma de análisis para equipos. Está disponible como una versión autohospedada, pero también como una versión SaaS. Luego tenemos GraphQL tools, que es una utilidad para todo tipo de herramientas de esquema y servidor GraphQL que puedas necesitar. Y también muy popular es GraphQL scholars, que es una biblioteca de validación de esquema y tipos de datos para GraphQL GS. Eso es solo una pequeña muestra de todo lo que tenemos. Puedes encontrar más información en guild.dev. Pero hoy vamos a hablar sobre GraphQL Yoga versión 3.

Antes de comenzar, déjame darte una breve descripción de lo que ha sucedido en el pasado. Cómo Yoga ha evolucionado y cómo hemos llegado hasta hoy. Intentaré ser breve. En algún momento del pasado, Yoga fue creado por Prisma y la razón de eso fue que en ese momento todas las soluciones de servidor GraphQL disponibles eran demasiado complicadas. Para las personas nuevas que comenzaban en el espacio de GraphQL, les resultaba difícil empezar realmente con GraphQL. Así que Prisma tomó el servidor Apollo existente, lo envolvió en otra capa y de ahí nació Yoga. Poco después, la comunidad vio este servidor GraphQL Yoga y, por razones obvias, facilidad de uso y baterías incluidas, comenzaron a adoptarlo. Luego, algún tiempo después, Prisma se alejó de GraphQL. Introdujeron su propio SDL, abandonaron GraphQL y, inevitablemente, GraphQL Yoga quedó sin mantenimiento durante mucho tiempo. Se acumularon muchos problemas en GitHub y otras discusiones. Ahí es cuando entró en escena The Guild.

Así que el año pasado nos acercamos al equipo de Prisma y les preguntamos cuál era su plan para Yoga y si deberíamos ayudarlos. Al final, adoptamos Yoga, nos transfirieron el repositorio y luego comenzamos a trabajar en él.

El primer hito que teníamos en mente era Yoga versión 2, y básicamente la misión detrás de Yoga versión 2 era devolver la biblioteca de Yoga a un estado en el que estuviera mantenida, se abordaran todos los problemas y comentarios existentes, se actualizaran las dependencias críticas, y sí, eso sucedió. Hace aproximadamente medio año, en junio, finalmente lanzamos Yoga versión 2. Y luego, hace apenas un mes, lanzamos GraphQL Yoga versión 3.

Pero, ¿qué sucedió desde GraphQL Yoga versión 2 hasta GraphQL Yoga versión 3? Eso es de lo que voy a hablar ahora. Así que en realidad, en junio, cuando acabábamos de lanzar GraphQL Yoga versión 2, todos los miembros de The Guild se reunieron en San Francisco y nos sentamos juntos a brainstormear sobre la visión del servidor GraphQL que todos teníamos. Cada uno tenía alguna visión, pero cada individuo en The Guild tenía diferentes necesidades, provenientes de diferentes entornos y trabajando en diferentes proyectos de clientes.

Después de muchas discusiones intensas, llegamos a los siguientes puntos clave que son valiosos. En primer lugar, debería ser fácil comenzar. Al igual que Yoga versión 1 era fácil de comenzar y Yoga versión 2 también lo era, queríamos mantener eso para Yoga versión 3. Luego, lo otro que queríamos hacer es hacer que Yoga versión 3 esté listo para producción por defecto. Con las baterías incluidas. Los detalles sobre esto los hablaré más adelante. También queríamos que GraphQL Yoga se adapte a cualquier stack existente. Y eso no significa, `oh, quiero usarlo con Express, o con Fastify, o quiero usar SDL primero, o code first`. Cuando dijimos que se adapte a cualquier stack existente, en realidad nos referíamos a cualquier JavaScript que exista, ya sea Deno, Bunn, Cloudflare Workers, queríamos darles soporte a todos. Además, queríamos ocultar la complejidad innecesaria, lo cual está relacionado con ser fácil de comenzar. Sí. También queríamos proporcionar soluciones para problemas comunes, como operaciones persistentes, Apollo Federation, todas esas palabras de moda que existen. Queríamos abordarlos y darles soluciones. Y finalmente, también queríamos permitir que las personas o individuos resuelvan sus propias necesidades específicas con yoga sin tener que abandonar yoga, o salir de yoga, o tener que bifurcar yoga, lo que básicamente significa que queríamos tener un sistema de complementos lo más potente posible.

Entonces, ¿cómo logramos todos esos puntos? Comencemos con la facilidad de comenzar. Configurar un servidor GraphQL con yoga es pan comido. Con este código a la derecha, obtienes un servidor GraphQL completo que admite todas las últimas características de GraphQL. Esto existe en Platform Primitives, en este ejemplo, estamos usando Node con el módulo HTTP. También puedes ver que yoga no abstrae el manejo de HTTP de Node. Es simplemente un escuchador de solicitudes que obtienes de la biblioteca de yoga y puedes conectarlo a cualquier servidor HTTP específico para Node o Cloudflare Workers o BAN o DNO. Y a partir de eso, obtienes todo, incluido un IDE de GraphQL.

Otra mejora que hicimos desde la versión dos de Yoga es que finalmente actualizamos a GraphQL 2, lo cual es increíble. Quedamos asombrados por ello. Obtienes una apariencia nueva y fresca, y una usabilidad mejorada, como 10 veces mejor. Además, GraphQL se ejecuta localmente en comparación con otros servidores GraphQL de código abierto, donde comenzaron a no incluir un IDE con el servidor GraphQL y en su lugar te incitan a usar su versión autohospedada o en la nube de Playground. Y lo mejor de GraphQL versión dos es que fue construido completamente por la comunidad. Es de código abierto y tenemos la intención de mantenerlo y mejorarlo aún más.

Otra cosa que debería ser fácil de usar son las suscripciones de GraphQL. En el pasado, se necesitaban WebSockets para hacer esto porque no había alternativas. Hay una larga historia e incidente entre las suscripciones de GraphQL que no se mantenían y la gente se enfadaba por ello. Y pensamos, vamos a probar un enfoque nuevo y vamos a intentar usar servidores y eventos, que básicamente es HTTP simple y no requiere ninguna sobrecarga de protocolo WebSocket personalizado. Nuestro objetivo era que puedas escribir tu suscripción de GraphQL y luego hacer una simple solicitud curl desde tu terminal para hacer que la suscripción funcione por completo. Y lo logramos. A la derecha puedes ver una configuración de suscripción simple y en la parte superior izquierda, inferior izquierda puedes ver una solicitud curl usando el encabezado accept text event stream, que indica que estamos tratando con un flujo de eventos de Nestervas. Y eso es todo. Obtendrás los eventos a medida que ocurran y, de la misma manera que funciona en curl, puedes consumirlos en tu navegador.

Otra característica que ha estado en discusión desde siempre y que pensamos que finalmente debería estar disponible en un servidor JavaScript de forma predeterminada es la deferencia de transmisión. Es una característica muy poderosa. Básicamente te permite dividir tu operación de consulta única en partes donde sabes que ciertas partes están disponibles más rápido y ciertos datos solo están disponibles más tarde porque son lentos, necesitan hacer una consulta a la base de datos o lo que sea. Simplemente dividiendo esos campos bajo demanda y luego transmitiéndolos a los clientes, se mejora mucho y con eso puedes construir aplicaciones mucho más receptivas. Hasta ahora, la única forma de usar esto en el mundo de GraphQL.js era instalar una versión experimental de GraphQL, hacerla funcionar con tu servidor existente. Pero lo resolvimos de diferentes maneras. Ahora puedes usarlo sin tener que lidiar con eso. Simplemente puedes usar GraphQL tal como está, GraphQL.js tal como está y usar Yoga para comenzar sin ninguna configuración adicional.

Otra cosa que debería ser fácil de comenzar es la prueba. En muchos marcos de JavaScript, la prueba siempre es una idea secundaria. No hay una forma documentada de hacer esas cosas. Queríamos asegurarnos con Yoga de que obtuvieras la experiencia completa y respuestas para todo. Pensamos que la mejor forma de prueba es en realidad usar la API fetch, porque así es como la mayoría de los desarrolladores están acostumbrados a llamar a las API en primer lugar. Pensamos, bueno, en la instancia de Yoga, simplemente expondríamos una función fetch que se comportaría exactamente como si llamara al servidor de Yoga desde mi navegador. De esa manera, puedes asegurarte de que las pruebas sean lo más cercanas posible al uso del mundo real.

Lo siguiente que queremos resolver es hacer que Yoga esté listo para producción de forma predeterminada. Como dije antes, solo con este código obtienes un servidor GraphQL completamente funcional. Pero además de eso, obtienes todo tipo de valores predeterminados listos para producción en segundo plano, que incluyen ocultamiento de errores, validación y almacenamiento en caché del analizador, comprobaciones de salud e incluso núcleos. Así que profundicemos un poco en ellos.

En primer lugar, el ocultamiento de errores. Todos saben que ocultar errores o filtrar errores a tus usuarios es una amenaza de seguridad. En este ejemplo, estamos llamando a una función loadUser en nuestro objeto DB. Esa es una llamada remota, ¿verdad? Intenta leer desde una base de datos o algo así. Imaginemos que has configurado incorrectamente las credenciales. Entonces la conexión podría fallar y, en lugar de resolver al usuario, en realidad se generará una excepción. Si esta excepción llega al usuario, habría un problema de seguridad. Por ejemplo, en este código, lo llevé un poco más arriba, donde el mensaje de error realmente contendría, en primer lugar, la IP y las credenciales para acceder a la base de datos. Eso sería fatal. Y lo que hacemos en su lugar con Yoga es ocultar eso por defecto para cualquier error o excepción inesperada que ocurra.

Luego, otro cuello de botella en muchos servidores GraphQL es la validación y el análisis. Para entender esto, primero debemos asegurarnos de que entiendas qué sucede cuando envías una solicitud GraphQL al servidor. Primero, tenemos un cliente que realiza una solicitud HTTP al servidor. Luego, el servidor es responsable de analizar el cuerpo de la solicitud y todos los parámetros, encontrar el controlador de ruta correcto y una vez que el servidor identifica que estamos tratando con una solicitud GraphQL, entra en acción el motor de ejecución de GraphQL. Y está compuesto básicamente por tres partes. Tenemos el análisis, la validación y la ejecución, y por lo general, los cuellos de botella son el análisis y la validación. ¿Por qué? Permíteme mostrarte.

Aquí tenemos un ejemplo de lo que hace el análisis. Antes, lo que el cliente envía al servidor es un documento de operación de consulta. Antes de que podamos procesar ese documento de operación de consulta, debemos convertirlo en un AST, un árbol de sintaxis abstracta, que es básicamente un formato intermedio que la capa de ejecución utilizará más adelante para resolver las fuentes de datos y los campos que se seleccionan dentro de la operación GraphQL. Y el problema con el análisis es que es lento porque está limitado por la CPU. El analizador básicamente recorrerá la operación GraphQL enviada y para cada uno de esos tokens calculará cosas. Y al final obtendrás el AST. Si ejecutamos la misma operación una y otra vez, no necesitamos analizarla una y otra vez. Lo que podemos hacer es simplemente agregar una caché LRU encima de la función del analizador y luego, cuando se ejecute la misma cadena dos veces, se puede proporcionar el AST en caché. Lo mismo ocurre con la capa de validación.

Entonces, en la capa de validación con el AST que acaba de ser analizado desde la capa del analizador, se validará con un conjunto de reglas. Por ejemplo, si un campo específico ya existe en nuestro esquema de GraphQL. En este ejemplo, tenemos una consulta MeQuery con un id y un nombre que pasará porque todos esos campos están disponibles en el esquema de GraphQL. En el segundo ejemplo, también tenemos un campo de contraseña que es solicitado por el cliente pero no existe en el servidor, por lo que en su lugar obtendremos un error que contiene 'no se puede consultar el campo contraseña en el tipo usuario'. La validación también es costosa porque necesita iterar a través de toda la operación de consulta y todos sus campos, pero como los resultados son los mismos para cada operación de consulta, podemos simplemente agregar una caché LRU entre ellos y el problema de rendimiento se resuelve.

GraphQL Yoga también incluye comprobaciones de salud de forma predeterminada. Por ejemplo, nuestros clientes y nosotros utilizamos Docker y Kubernetes en gran medida, y allí necesitas comprobaciones de preparación, comprobaciones de actividad, y cosas así. Está integrado en Yoga de forma predeterminada porque creemos que cada servidor GraphQL o servidor HTTP debería tener valores predeterminados incorporados para esto en este momento. Eso es el estándar de la industria. Además, Yoga se ocupa de Cross. No quiero entrar en detalles porque, ¿quién realmente entiende Cross? Simplemente funciona bien.

Lo siguiente que queremos abordar es que Yoga encaja en cualquier stack existente. Como dije antes, no estamos hablando de Node.js y todos los marcos de trabajo que se construyen a su alrededor. También quiero hablar sobre esos nuevos entornos de ejecución de JavaScript, Cloudflare Workers, Deno y BAM. Para cada uno de ellos, queríamos proporcionar una forma fácil de usarlo y también de extenderlo. Si observamos nuestro ejemplo de Xpress, es solo ligeramente diferente al de usar el módulo Node HDB. En lugar de simplemente pasarlo a la función create server, creamos nuestra aplicación Xpress y luego usamos Yoga como middleware para Xpress. Fácil como pastel. Si observamos BUN, también podemos crear nuestro controlador de solicitud de Yoga, pasarlo a BUN y eso es todo. Lo mismo para Deno. Creamos nuestro controlador de solicitud, lo pasamos a la función de servidor específica de Deno, eso es todo. Y también para Cloudflare Workers, creamos nuestro escucha de solicitud de Yoga, lo adjuntamos al evento fetch, eso es todo. ¿Cómo funciona eso? Porque todas esas plataformas son bastante diferentes entre sí. Bueno, la solución aquí es el modelo de solicitud y respuesta, que se hizo popular gracias a la API Fetch. Básicamente, la idea es que el escucha de solicitud recibe un objeto de solicitud y devuelve un objeto de respuesta. Esto se hizo muy popular por los trabajadores de Cloudflare que lo adoptaron inicialmente. Y lo tomaron inicialmente de la API Fetch. Entonces, dentro del navegador, tenemos solicitud y respuesta desde hace mucho tiempo, pero ahora también lo tenemos en los entornos de ejecución de servidor de JavaScript. Todos esos nuevos entornos de ejecución de JavaScript, Deno, BARN y Cloudflare Workers, ya adoptaron esta forma de manejar solicitudes HTTP. El único entorno de ejecución de JavaScript que está un poco atrasado en ese sentido es Node. Para seguir admitiendo esto con Node.js, simplemente creamos un pequeño polyfill o adaptador muy ligero que soluciona esta brecha hasta que Node.js se ponga al día.

Y esta pequeña capa en realidad forma parte del núcleo de Yoga. Quiero agradecer aquí a Ada, quien hizo todo esto posible y tuvo la idea inicial. Así que, al construir el motor de GraphQL y el servidor HTTP en torno a estos parámetros, obtuvimos algo que realmente funciona en todas partes.

Otra parte importante para nosotros al encajar en un stack existente es que la construcción del esquema debería ser posible de cualquier manera. Yoga no debería tener una opinión sobre cómo construir el esquema. De hecho, incluimos una utilidad para construir un esquema basado en SDL, pero no es obligatorio. Si no quieres usarlo, no estará en tu código. Por ejemplo, si implementas Yoga en Cloudflare Workers, empaquetarás tu código. Y nos aseguramos de que Yoga admita el tree shaking. Si no usas las utilidades, no formarán parte del paquete. Puedes elegir tu preferencia, ya sea usar SDL primero, usar las herramientas de GraphQL o los módulos de GraphQL si estás en el sector empresarial, o si quieres hacer código primero con GraphQL.js, no recomendado, POTUS o GQTX. Es tu elección. Tu esquema, Yoga acepta cualquier esquema de GraphQL.

Luego, el siguiente paso para nosotros fue asegurarnos de que Yoga sea completamente extensible. Con Yoga versión 2, ya nos aseguramos de que el análisis, la validación, la ejecución y la suscripción sean completamente extensibles, gracias al motor de envoltura. Pero para Yoga versión 3, queríamos ir un paso más allá. En lugar de solo permitir la extensión de las cosas específicas de GraphQL, también queríamos permitir tener el control total del flujo HTTP. Eso significa, intervenir en el enrutamiento, intervenir en el análisis de la solicitud, intervenir en la construcción de la respuesta , además de los hooks existentes para el análisis, la validación y la ejecución. Y a partir de eso, pudimos construir plugins muy potentes, uno de los cuales voy a mostrar ahora, del cual estamos muy orgullosos, es la caché de respuestas. Básicamente, es una caché para operaciones de GraphQL, por lo que si ejecutas una operación de consulta con las mismas variables una y otra vez, puedes almacenarla en caché ya sea de forma global o por sesión de usuario. Y luego, cuando se ejecuta la operación de GraphQL por segunda o tercera vez, los resultados se sirven desde la caché en lugar de tener que volver a ejecutar la operación completa de GraphQL. Eso puede reducir drásticamente la carga del servidor y puedes almacenar los resultados de ejecución de GraphQL en memoria. O si tienes múltiples réplicas del servidor, puedes usar Redis o Upstash como una caché alternativa para compartir entre múltiples instancias.

Otra cosa son las Consultas Persistentes Automáticas. Eso fue popularizado por Apollo, y básicamente es un protocolo para registrar operaciones de GraphQL recurrentes en un servidor para reducir el tráfico entre el cliente y el servidor. Entonces, un cliente puede enviar una operación, registrarla y luego, si necesita volver a ejecutar la operación de GraphQL, solo puede enviar un hash en el segundo intento, y el servidor ya conoce la operación a partir de ese hash, por lo que el tráfico entre el cliente y el servidor es muy bajo, porque lo que vimos es que generalmente, a medida que las operaciones de GraphQL se vuelven muy grandes, el cuello de botella más grande en todo el escenario de cliente a servidor es en realidad el cliente que sube el documento de GraphQL al servidor, y como antes, solo tienes que conectar tu plugin y eso es todo.

Otra cosa es la operación persistente, que es un poco similar a las consultas persistentes automáticas, pero también agrega otra capa de seguridad, porque donde las consultas persistentes automáticas permiten registrar consultas ad hoc y ahorrar ancho de banda, las operaciones persistentes solo permiten ejecutar operaciones específicas con antelación. Entonces, cualquier otra operación de GraphQL, excepto aquellas que están en el almacenamiento de operaciones persistentes y que intenta ejecutarse, será rechazada. Y este es un patrón que generalmente usamos en implementaciones de producción de GraphQL, porque generalmente queremos evitar cualquier consulta arbitraria de clientes que no conocemos. Otra cosa que encontramos muy interesante es, ¿qué pasa si tomamos una API o esquema de GraphQL y la convertimos en una API REST? Hoy en día, tenemos muchos debates sobre, oh, GraphQL versus REST, ¿cuál es mejor? Creemos que ambos tienen sus casos de uso.

¿Por qué no desarrollar tu esquema como un esquema de GraphQL y luego convertirlo en una API REST? Con este plugin, también obtienes la experiencia completa de Swagger, donde puedes probar tus puntos finales y documentarlos, similar a lo que GraphQL hace por GraphQL. Otra cosa de la que estamos realmente orgullosos y muy contentos por la colaboración es GraphQL Armor, que es una colección de plugins de seguridad mantenidos por nuestros amigos de Escape y básicamente proporcionan muchas utilidades o plugins para APIs públicas de GraphQL.

Entonces, si estás construyendo una API privada de GraphQL y quieres ir a producción, probablemente las operaciones persistentes sean tu mejor opción, porque esto permite ejecutar operaciones arbitrarias. Pero si tu producto principal es la API de GraphQL y tienes muchos clientes y no puedes determinar qué tipo de operaciones de GraphQL se ejecutarán de antemano, tener un conjunto de plugins de seguridad que eviten el uso excesivo de la API de GraphQL es obligatorio, en nuestra opinión. Algunos de los plugins que son realmente geniales son Token Limit, que básicamente limita la cantidad de campos y tokens que una operación de GraphQL puede contener. Luego tenemos Operation Cost Limit para que puedas asignar un peso a los campos dentro de tu esquema de GraphQL. Y si se ejecuta una consulta que excede ese límite de costo de consulta, se rechaza automáticamente. Depth Limiting, uno clásico, probablemente el más conocido en el espacio de GraphQL. Una vez que tu consulta de GraphQL excede cierta profundidad, simplemente se rechaza y también deshabilita las sugerencias de campos si quieres evitar que las personas adivinen automáticamente tu esquema. También admitimos Apollo Federation. Por lo tanto, GraphQL Yoga puede ser tanto una puerta de enlace como un subgrafo. Puedes disfrutar de todos los beneficios que obtienes del ecosistema de Apollo y usarlos en el ecosistema de Yoga. Y si eso no es suficiente, aún puedes escribir tus propios plugins, ¿verdad? Yoga tiene una API completamente flexible para conectarse a cualquier cosa relacionada con HTTP y GraphQL, y puedes resolver tus necesidades o problemas específicos de tu caso de uso con tus propios plugins. Y si tu plugin resuelve un caso de uso genérico y crees que otras personas se pueden beneficiar de él, puedes compartirlo con la comunidad. En el sitio web de Envelope, tenemos básicamente un centro de plugins con más de 40 plugins que son mantenidos por el Guild o miembros de la comunidad, todos relacionados con el manejo de errores, métricas, trazabilidad, autenticación, autorización, almacenamiento en caché y seguridad. Si has creado un plugin genial, contáctanos y podríamos presentarlo allí, porque podría ayudar a otras personas además de ti.

Y la última cosa que queríamos asegurarnos es que GraphQL Yoga realmente ha sido probado en producción. Nuestro acorazado para probar cosas es GraphQL Hive, que es nuestro registro de esquemas que sirve miles de millones de solicitudes cada mes. Antes de lanzar la versión 3 de GraphQL Yoga, ya lo estábamos ejecutando en Hive durante mucho tiempo. Además, nuestros buenos amigos de Redwood.js y ParseRer ya están experimentando con la versión 3 de GraphQL Yoga y estamos colaborando con ellos y actualizando esas cosas, construyendo un camino de migración para sus usuarios. Eso es todo lo que tengo que decir hoy. Mi última sugerencia para ti es que pruebes la versión 3 de GraphQL Yoga. Gracias.

¡Hola! Hola, qué bueno tenerte aquí. Gracias por recibirme. Entonces, primera pregunta, primero veamos la pregunta de la encuesta. Le preguntaste a la gente qué características de GraphQL próximas son las que más les entusiasman. Veamos la respuesta. Lo más interesante es que la respuesta más popular fue la directiva one-off. Justo después de eso, el flujo de diferimiento y muy por detrás están los argumentos de fragmento y la confiabilidad del control recuperado.

Sé que tienes muchas opiniones sobre cada una de ellas. Tal vez puedas describir muy rápidamente, ¿sabes, qué es cada una y por qué crees que son importantes? Sí, claro. Entonces, la directiva one-off está ahí para resolver el problema de las uniones de entrada. Básicamente, si tengo una mutación hoy, tengo un tipo de entrada, no hay nada como una unión. Y por eso existe esta propuesta de la directiva one-off. Puedes anotar tu tipo de entrada con add one-off. Y luego tienes básicamente uniones de entrada. Es probablemente también mi favorita, solo para provocar un poco. Es que, con GraphQL, teníamos esta cosa. Primero, teníamos diferentes puntos finales, como puntos finales individuales para obtener datos, la gente quería ponerlo en un gráfico y obtener todo junto. Pero luego se dieron cuenta de que, oh, no, las cosas son lentas porque tenemos que esperar hasta que se carguen todos los datos. Entonces, este es en realidad un concepto inteligente para, luego, anotar ciertas cosas en los datos que queremos obtener, y luego obtener eso tan pronto como esté disponible, básicamente transmitirlo al cliente.

Y luego también están los argumentos de fragmento, que en mi opinión es muy interesante. Si estás usando algo como Relay, o en general usas fragmentos para componer tus componentes, porque luego puedes componer todos tus fragmentos, pasar argumentos a esos fragmentos y construir un único documento de consulta para toda la vista de tu aplicación. Y luego la nulabilidad controlada por el cliente es un poco exótica. Aún no lo he entendido al 100%, pero he hablado con varias personas al respecto, y ven el principal beneficio en ello, no para los clientes normales que intentan escribir consultas de GraphQL, sino más bien para las pasarelas. Porque lo que permite la nulabilidad controlada por el cliente es romper las reglas normales que existen en GraphQL hoy en día. Por ejemplo, si tienes una pasarela que agrupa diferentes consultas en una sola operación de consulta y ocurre un error, la operación se escalaría hasta el siguiente campo anulable, y eso podría eliminar otras respuestas del resultado de la consulta. Y si puedes sobrescribir este comportamiento para una ruta determinada, puedes solucionarlo. Así que para mí, es más una característica de las pasarelas y también por qué muy pocas personas votaron por ella.

Por cierto, solo quiero recordarles a las personas que si tienen preguntas, pueden ir a Discord en el canal de preguntas y respuestas de Dromeda y preguntar. Supongo que la primera pregunta para mí, incluso relacionada con esta encuesta, es si las personas quieren usar estas características hoy mismo y obtener sus beneficios, ¿qué pueden hacer? En cuanto a las uniones one-off, tenemos un plugin para esto en Joga. Inicialmente, construimos este plugin para Envelop, pero puedes usar todos los plugins de Envelop con Joga. Luego, para el flujo diferido, también tenemos un plugin de Joga. En el pasado, era muy difícil de usar. Lo hemos facilitado. Y para la nulabilidad controlada por el cliente, no hay ningún plugin y, obviamente, aparentemente, no hay demanda para ello. Y la última característica, ya me olvidé de la última característica. ¿Cuál era? Argumentos de fragmento.

Genial. Así que tenemos un minuto, así que tal vez una última pregunta. Entonces hablaste de Yoga v3. ¿Cuál es tu característica favorita de Yoga que crees que debería emocionar más a la gente? En mi opinión, es el flujo diferido. Es alucinante, porque resuelve un problema real que tienen las personas que se están pasando a GraphQL. Sí, así que esa es probablemente mi favorita. Genial. Sí, muchas gracias, Lauren. Esto fue realmente emocionante y genial tenerte aquí. Y, por supuesto, estoy muy emocionado por todo lo que está por venir a Yoga, pero aquí soy muy, muy parcial. Y, sí, gracias por la charla. Cecilia, te toca a ti. Gracias.