GraphQL en cualquier lugar - Nuestro viaje con GraphQL Mesh y Schema Stitching

Soy miembro de un grupo llamado The Guild. Somos el grupo de código abierto más grande en el mundo de GraphQL, por lo que probablemente estés usando una de nuestras bibliotecas, como tal vez el Generador de Código GraphQL para generar código a partir de tus esquemas y tus operaciones. Inspector GraphQL para asegurarte de rastrear cambios y asegurarte de que no estás haciendo cambios que rompan algo. Módulos GraphQL que presentamos recientemente en la versión 1.0 después de muchos años de iteraciones. Es una herramienta que te ayuda básicamente a dividir las responsabilidades de tu puerta de enlace GraphQL entre equipos, manteniendo aún una puerta de enlace GraphQL regular. Herramientas GraphQL que mencionaré más adelante hoy, principalmente en torno a la enseñanza de nuevos esquemas que si pensabas que estaban obsoletos, entonces quédate para esta charla y espero que puedas aprender algunas cosas nuevas al respecto. Malla GraphQL que te permite consultar fuentes que no son GraphQL como si lo fueran GraphQL automáticamente y muchas otras.

Menciono todas estas herramientas porque para nosotros el objetivo de The Guild es, con el fin de crear una comunidad poderosa, creemos que necesitamos confiar en muchas herramientas que se mantienen y en las que puedes contar a largo plazo. Eso es lo que hacemos. Lo hacemos nosotros mismos y lo hacemos con la comunidad. Podrías, ya sabes, usar todas esas herramientas juntas como una plataforma y todas tienen una visión detrás de ellas, pero cuando vamos a un cliente muy grande o algo así, no podemos simplemente introducir todas esas herramientas, las construimos individualmente para que puedas introducir lentamente y gradualmente esas herramientas cuando las necesites, solo las cosas que necesitas. Pero nuevamente, como dije, no podemos hacer esto solos.

Entonces, en el último año, nos unimos a la Fundación GraphQL para también ayudar a influir y contribuir a los activos principales de GraphQL, como GraphQLJS y GraphQL.org. En GraphQLJS, en realidad comenzamos nuevamente el esfuerzo de migrar GraphQLJS a TypeScript. Necesitamos ayuda allí, por cierto, así que puedes ir a GraphQLJS y los problemas destacados están relacionados con la migración a TypeScript. Cualquier ayuda será útil. También mejoramos mucho GraphQL.org en sí. Hemos reconstruido por completo su infraestructura utilizando Gatsby para facilitar la contribución. También reconstruimos la página de código. Será mucho más fácil encontrar las bibliotecas que deseas y que están bien mantenidas. Ve allí y básicamente encontrarás todas las bibliotecas que mencionaré ahora destacadas allí, y esperamos que se convierta en la mejor fuente disponible. Y si quieres contribuir, ahora es más fácil. Es mejor y más fácil que nunca.

También mencionaré algunas cosas emocionantes que han sucedido en la comunidad que no son de nuestra autoría y que nos alegran, como la nueva biblioteca GraphQL Web Socket. Durante años, hubo una biblioteca que no se mantenía, y Dennis de la comunidad básicamente construyó una nueva biblioteca, creó un grupo de trabajo en torno al protocolo y lo hizo más seguro y fácil de integrar. Si alguna vez has intentado las suscripciones de GraphQL o has necesitado un protocolo de Web Socket, ahora es más fácil que nunca.

Además, durante años hemos hablado sobre las directivas stream y defer, y lo valiosas que podrían ser, y este año Liliana y Rob de First Dibs realmente trabajaron mucho tiempo para incluirlas en la especificación y en la referencia y limitación, para que puedas usarlas hoy. Otra directiva que es muy interesante aún no está en la especificación, pero creo que tiene un futuro muy prometedor y podría ayudar a mucha gente, es la directiva Live Queries. Lauren de la comunidad creó el repositorio y las bibliotecas de GraphQL Live Query, y creo que deberías echarle un vistazo. Personalmente, estamos muy emocionados al respecto.

Y otra cosa que no es un gran secreto es que muchas de las bibliotecas populares en la comunidad no están bien mantenidas y no se actualizan. Aunque tenemos todas estas nuevas bibliotecas, es difícil integrarlas en tu servidor. Pero recientemente Daniel tomó ese problema. Daniel de la comunidad lanzó GraphQL Helix, que ya estamos usando en producción. Lo recomendamos altamente. Es un marco GraphQL muy ligero. Puedes usarlo con cualquier otro marco como Express o Festify, entre otros. Y puedes aprovechar todas las nuevas características de GraphQL. Así que lo recomendamos mucho. Y por supuesto, está el gran trabajo que Riqui ha estado haciendo en GraphiQL y los servicios de lenguaje de GraphQL. Hay muchas cosas emocionantes en las que confiamos con nuestras propias herramientas. Ha sucedido mucho y estamos muy emocionados al respecto. Pero lo más interesante es que la mayoría de ese trabajo lo están haciendo personas individuales, y queremos apoyar a otras personas que también están haciendo ese trabajo. Si necesitas ayuda, si tienes ideas, si quieres contribuir, creemos que ahora es más fácil que nunca. Y si encuentras algún obstáculo, avísanos y esperamos poder ayudarte con eso.

Así que ahora comencemos con la charla real. El objetivo de la charla real es presentarte cómo nosotros, el Guild, introducimos GraphQL en bases de código grandes. Lo hacemos todo el tiempo con clientes muy grandes, y hemos aprendido algunas cosas que funcionan y otras que no funcionan para nosotros. Así que espero poder compartir contigo esas lecciones, compartir las herramientas que usamos para que tú también puedas usarlas, y espero que te ayuden, y tal vez puedas aprender también de nosotros qué no hacer. El título de este plan es Gradual y Distribuido. Espero que pienses en ese título cada vez que quieras usar nuestras herramientas o durante esta charla. GraphQL es genial, no voy a hablar de por qué aquí, pero vamos a repasar los conceptos básicos para ver dónde realmente puede ayudarnos. GraphQL puede ayudarnos a describir los datos y la conexión entre ellos, y luego podemos consultarlos.

En este ejemplo, un cliente puede consultar a un servidor o múltiples servicios, luego el motor de GraphQL ayudará a orquestar todas esas llamadas diferentes, y para el cliente será simplemente una obstrucción. El cliente enviará una solicitud y recibirá una respuesta en la forma que solicita, solo los data que solicita, pero también todo el trabajo detrás de escena, la orquestación que se está automatizando, se está obstruyendo para el cliente o el consumidor.

Así que podemos ver aquí el rendimiento de la red del que todos hablan, pero también podemos ver que tenemos un esquema de nuestro gráfico de data, básicamente algo que explica el data real que queremos consumir. También podemos ver desde ese esquema las relaciones y las conexiones para el producto, de una manera explícita, y también obtenemos orquestación y automatización.

Entonces la pregunta es, ¿por dónde deberíamos empezar a usarlo? Y al responder esa pregunta, nos preguntamos, ¿dónde se encuentra esa lógica actualmente? Porque ese podría ser el lugar más fácil para comenzar. En lugar de introducir una nueva arquitectura, esperamos poder automatizar cosas que actualmente se hacen manualmente. Para nosotros, lo que vemos mucho es que esta lógica actualmente se encuentra en el cliente, en clientes móviles o clientes web. Básicamente, usan REST hoy en día, envían múltiples llamadas y luego hacen mucho trabajo manual para reestructurar los data y prepararlos para renderizar en la interfaz de usuario.

Entonces, cuando comenzamos a usar, integrar GraphQL en servicios, en empresas, generalmente lo que hacemos es introducir GraphQL en el cliente. Y te sorprenderá lo popular que es esa forma de introducir GraphQL. No se habla mucho de ello, pero es extremadamente popular. Lo vemos mucho. De esa manera, puedes comenzar a automatizar mucho del trabajo. Los equipos pueden comenzar a aprender GraphQL. Es fácil porque es mucho más fácil introducir una dependencia pequeña en una aplicación de cliente que agregar un nuevo servidor o cambiar la arquitectura o cosas así. Las personas pueden comenzar a aprender y comprender los beneficios. Y luego, más adelante, una vez que estemos creciendo gradualmente en el mundo del frontend y obteniendo muchos de esos beneficios, en ese momento, podemos mover ese código o esa orquestación al servidor cuando lo consideremos necesario. Así que hay muchos beneficios de hacer eso en el cliente. Tengo una charla completa al respecto. No repetiré la charla hoy. Pero una vez que introducimos GraphQL entre el cliente y el motor de GraphQL, ¿qué pasa con las fuentes de data? Quiero decir, todavía estamos consultando las mismas fuentes de data que antes. Y en nuestros resolvers, por ejemplo, todavía llamamos a los mismos puntos finales de REST que solíamos usar antes. Entonces, lo que pensamos es, ¿cómo podríamos comenzar a integrar esos beneficios de GraphQL también en los servicios del backend, para que comprendan lo que se les está consultando, para obtener un esquema? Para obtener, nuevamente, en lugar de simplemente enviar una llamada REST, tal vez enviar una consulta de GraphQL. Muchas veces, las personas realmente comienzan a convertir sus servicios existentes o los antiguos servicios que tenían en GraphQL, lo cual tiene sentido en algunos casos, pero en la mayoría de las empresas no es factible. Esos equipos ya tienen suficiente trabajo. O tal vez esas fuentes ni siquiera son mantenidas por nosotros o por nuestros equipos y llevará años hacerlo. Entonces, lo que intentamos hacer es pensar, bueno, esas fuentes todavía están ahí, están funcionando, tal vez tengan esquemas como gRPC o esquemas de OpenAPI y Swagger. Tal vez no tengan ningún esquema, pero puedo ver las respuestas existentes y tal vez generar esquemas JSON a partir de ellas. Entonces, si tenemos toda esa información, ¿por qué no podemos tomar esa información y convertirla automáticamente en esquemas de GraphQL? Y eso es GraphQL Mesh, que espero que muchos de ustedes ya hayan escuchado. Y nuevamente, la idea es tomar la información que tenemos de las fuentes existentes y generar y convertir automáticamente esta información en GraphQL.

Entonces, GraphQL Mesh tiene muchos controladores. Puedes convertir OpenAPI y Swagger, gRPC, SOAP, SQL e incluso OData y muchos otros. Y ahí es donde realmente puedes comenzar a consultar GraphQL en esas fuentes sin que ellas siquiera sepan qué es GraphQL. Así obtienes los beneficios instantáneamente, lo que facilita la adopción. Las personas pueden comenzar a consumir GraphQL aunque las fuentes no lo sean.

Ahora, eso es GraphQL Mesh. Una vez que comenzamos a hacer eso, la siguiente fase es en realidad, ya sabes, tenemos múltiples fuentes, algunas de ellas no son convertidas a GraphQL, algunas de ellas son en realidad GraphQL, pero debido a que GraphQL se basa en un grafo de datos, podemos tomar todas esas diferentes fuentes ahora y fusionarlas en una sola fuente de GraphQL. Entonces, ¿cómo lo hacemos en la comunidad hoy en día? Tomando múltiples fuentes de datos GraphQL y fusionándolas en una, como aquí. Y en este caso, con GraphQL Mesh, nuevamente, pueden ser cualquier fuente, pueden ser GraphQL o no GraphQL. Entonces, ¿cuál es la solución en la comunidad hoy en día para eso? Apollo Federation. Así es, Apollo Federation es una técnica muy interesante que te ayuda a tomar múltiples fuentes de GraphQL y fusionarlas. Tiene muchos beneficios, pero también significa que hay muchas herramientas y cosas específicas que necesitas usar para aprovechar Apollo Federation. Pero lo que sucede es que con GraphQL Mesh, elegimos no usar específicamente GraphQL Federation. Elegimos darte la opción. Puedes usar Apollo Federation, pero también puedes usar Schema Stitching.

Ahora, quiero hablar un poco sobre Schema Stitching por un momento, porque durante muchos años la gente pensó que Schema Stitching estaba obsoleto. Lo que sucedió con Schema Stitching en realidad es que Apollo decidió pasar a Apollo Federation y no invertir más tiempo en Schema Stitching. Pero para nosotros, que trabajamos con muchos clientes que utilizan Schema Stitching, vimos que en muchos casos, Apollo Federation no reemplazó por completo a Schema Stitching. Así que lo que hicimos fue hacernos cargo de las herramientas de GraphQL de Apollo y básicamente seguir manteniéndolas y mejorándolas. Y hoy quiero mostrarte que GraphQL y Schema Stitching no solo son una alternativa a Apollo Federation, sino que en muchos casos son incluso mejores. Entonces, con GraphQL Mesh, nuevamente, no elegimos por ti. Puedes elegir entre Apollo Federation y Schema Stitching. Lo que ves aquí parece tal vez como Apollo Federation, pero en realidad es Schema Stitching. Es una forma de tomar, quiero que mires, básicamente este es un servicio específico que utiliza, el gateway es en realidad un gateway de Schema Stitching que toma esa fuente y la fusiona con otras fuentes. Lo interesante de ese código, no voy a profundizar demasiado en eso porque no tengo mucho tiempo, pero esta es la parte más interesante. Esta fuente es simplemente GraphQL. Puedo usar eso con GraphQL Express, o GraphQL Helix, Apollo Server, cualquier fuente que quiera. Y eso significa que todas las cosas nuevas que mencioné al principio de la charla, todas las nuevas cosas que ahora, la gente podría usar con GraphQL, podrías usarlas con Schema Stitching. Así de simple, es GraphQL. No tienes que comprar un ecosistema separado, no tienes que comprar una lista completa de productos.

Como dije al principio de la charla, de manera gradual y distribuida, puedes utilizar la fusión de GraphQL y fuentes remotas sin tener que comprar un producto completo. Para profundizar en eso, desafortunadamente no lo haré hoy porque tengo más cosas que mencionar, pero creo que deberías echar un vistazo a este repositorio de Greg, demos de schema stitching. Lo que está sucediendo allí es que puedes ver demos de los últimos schema stitching. Primero, lado a lado con algunas demos de Apollo Federation para comparar. En segundo lugar, puedes ver cosas como cómo usar suscripciones con schema stitching y también cómo recargar en vivo servicios específicos en tu puerta de enlace. Si están lanzando una nueva versión y cómo puedes dejar la puerta de enlace y recargar en vivo otros cosas en ella. Es muy, muy interesante y seguimos, al igual que todas nuestras otras herramientas, mejorándola gradualmente. Y también queremos tus comentarios.

Ahora, como dije, de manera gradual y distribuida. Ahora, una vez que tenemos todas las cosas que acabo de mencionar, es decir, podemos tomar diferentes fuentes, GraphQL o no, convertirlas en GraphQL, luego fusionarlas usando Apollo Federation o schema stitching. Y ahora tenemos este lugar central al que podemos hacer consultas y con un solo gráfico, ¿verdad? Pero la cuestión es que también nos importa la distribución. Entonces, no... creemos que podrías obtener todos esos beneficios, obtener ese único gráfico, obtener todas esas cosas juntas, pero en lugar de hacer que todo pase por una puerta de enlace central o un punto central que podría ser un punto de falla, con GraphQL Mesh y schema stitching, en realidad podrías obtener todos esos servicios diferentes, inspeccionarlos. Y luego, además de crear una puerta de enlace, puedes generar SDK. Ahora, cada servicio puede hacer consultas directamente a todos esos servicios diferentes, por eso se llama GraphQL Mesh, porque puede ser una malla de servicios y esos SDK pueden estar en tu capa de procesamiento de datos o en tu servicio de procesamiento de datos en tu puerta de enlace e incluso en el cliente. Entonces, podrías obtener esta experiencia de un solo gráfico, pero no tienes que ejecutar todo eso a través de un lugar central.

Ahora, y sabes, solo para darte un ejemplo de cómo lo usamos a veces, aprovechando todo eso poder, pero usándolo en un caso de uso muy simple para comenzar, hoy tienes resolvers. Ya escribiste un servidor regular de GraphQL, tienes resolvers. Esperemos que, si estás usando TypeScript, hayas generado las entradas y salidas de esos resolvers usando el generador de código de GraphQL. Pero luego, cuando llamas a los servicios remotos, no tienes tipos, llamas al mismo antiguo punto de REST. No tienes tipos y puedes hacer consultas. Pero si aprovechamos todo el poder que acabo de mencionar, pero lo generamos en un SDK simple, podemos obtener todos esos tipos y realmente obtener un SDK potente que puede hacer consultas a todos los servicios en nuestro ecosistema. Y ese es en realidad el caso de uso más popular que vemos hoy para GraphQL Mesh. Puede ser una puerta de enlace muy potente, pero también puede ser una fuente de datos mucho mejor para ti. Por lo tanto, hoy puedes integrarlo en tus servicios existentes de GraphQL. Esa es la belleza y el poder de tener algo que tiene todo el conocimiento, todo el poder de todo lo que mencioné, pero que simplemente se puede compilar en un SDK.

Ahora, para tener ese SDK, necesitamos, en algún lugar, pero aún así tenerlo distribuido, ¿dónde guardaríamos toda esa información, todos los esquemas de todas esas fuentes diferentes? Ese es el problema que falta aquí. Y queremos el GraphQL distribuido, pero también queríamos información de un solo gráfico. ¿Cómo lo hacemos? La respuesta es simple. Solo necesitamos el registro.

Solo necesitamos un lugar para que todos esos servicios diferentes se registren y digan: hey, este es mi esquema. Ese esquema puede ser GraphQL, puede ser OpenAPI, puede ser cualquier cosa. Podemos ir a ese registro, verlo o verlo simplemente como usuarios que intentan implementar algo, o verlo como código que luego generaría un SDK. Y luego generar solo código que podría ejecutarse en cualquier lugar.

Entonces, separamos la idea de tener todo en un solo lugar y el tiempo de ejecución. Y creo que esa es una idea muy poderosa. Hoy en día ya tenemos ese registro en funcionamiento en todos nuestros clientes. Es algo que vamos a abrir al público. Se llama GraphQL Hive. Queremos iterar un poco más sobre él y luego abrirlo al público. Entonces, si quieres probarlo, ya puedes hacerlo. Pero la idea es que ya puedes usarlo hoy en tu propio registro y en cualquier otra solución de registro que tengas hoy, solo guarda esos esquemas en algún lugar y ajústalos de nuevo en GraphQL Mesh.

Entonces, nuevamente, la idea de GraphQL Hive es que todas las diferentes herramientas que acabo de mencionar trabajen por separado, pero si quieres obtener los beneficios de todas ellas juntas, puedes tenerlas en un registro. Puede ser nuestro registro. Puede ser tu registro. Puedes elegir lo que quieras. Entonces, para nosotros, resumiendo todo lo que dije hoy, el flujo de trabajo de GraphQL es lo más importante. ¿Cuál es el flujo de trabajo que GraphQL nos permite y luego podemos elegir las herramientas que queremos y usarlas gradualmente y donde queramos de manera distribuida? Queremos ejecutar en cualquier lugar. Podríamos usar GraphQL Mesh y schema stitching, básicamente construir esas estrategias de fusión, pero luego ejecutarlo en todas partes. Todavía queremos el único gráfico. Todavía queremos ver toda la organización y queremos ordenar todo el desorden que está sucediendo, por lo que aún podemos recopilar todos esos esquemas y ponerlos en un registro como GraphQL Hive. Y nuevamente, sin la necesidad de unirlos en el tiempo de ejecución, para que no tengamos un punto central de falla, aún obtenemos los beneficios del orden. También podemos, ya sabes, algunas cosas que no mencioné, podemos comenzar a hacer cumplir reglas. Por eso lanzamos recientemente la biblioteca de ESLint de GraphQL. Podemos comenzar a hacer cumplir reglas y, ya sabes, colaboraciones y tener mejores prácticas en toda la empresa, nuevamente sin hacer que las personas pasen por una puerta de enlace central. Podríamos, simplemente, ya sabes, compartir las reglas en lugar de compartir la ejecución. Lo mismo ocurre con el seguimiento, por cierto, y la visibilidad. Ya sabes, una vez que tenemos todos esos diferentes entornos en funcionamiento, podemos recopilar todos los datos individualmente de cada una de esas diferentes fuentes. Podemos almacenarlos en cualquier lugar dentro de tus herramientas existentes hoy, porque probablemente ya lo estés haciendo.

Y luego puedes visualizar eso de forma centralizada. Entonces, si tomas todas tus herramientas existentes y simplemente las conectas a GraphQL Inspector y GraphQL Hive, puedes comenzar a obtener todos los beneficios de una herramienta integrada sin la necesidad de conformarte a un solo ecosistema.

Y lo más importante que quiero decir hoy es que ni siquiera necesita ser GraphQL. Todas esas cosas y todas las herramientas que construimos que son capaces y nos brindan muchas de esas habilidades, en realidad podemos tomar una fuente que no es GraphQL, convertirla en GraphQL usando GraphQL Mesh, y obtener todos o al menos algunos de esos beneficios. Entonces, nuevamente, así es como introducimos GraphQL en diferentes lugares. Así es como evitamos errores. Así es como nos aseguramos de no invertir demasiado pronto en soluciones que dentro de uno o dos años no serán beneficiosas. Y también podemos utilizar las soluciones existentes y fuentes existentes que las empresas tienen para llegar a donde queremos estar. Entonces, nuevamente, de forma gradual y distribuida. En resumen, creemos que para tener éxito en estas cosas, debes obtener las cosas que necesitas solo cuando las necesitas. Y puedes hacerlo, no necesitas invertir en todo un ecosistema antes de comprender los beneficios. Gradual y distribuido. Para obtener más información, puedes ir a gil.dev. Desde allí, puedes acceder a nuestro foro, comunicarte directamente con nuestro chat en línea, acceder a todas nuestras bibliotecas de código abierto en GitHub. Y básicamente, queremos saber de ti. Queremos obtener más comentarios. Estamos mejorando gradual y distribuidamente todas esas herramientas por separado y juntas. Así que necesitamos tu ayuda. Trabajamos en ellas individualmente, pero queremos trabajar juntos contigo. Muchas gracias. De tu encuesta. ¿Cómo te sientes al respecto? Sí, bueno, lo puse como una pregunta trampa. Esperaba las respuestas, y las respuestas fueron bastante divertidas. Así que gracias a todos por intentar responder. Algunas fueron buenas. Algunas fueron malas. La mayoría fueron divertidas. Así que gracias. Súper divertido. También hay una respuesta que dice: Uri lo hizo genial.

Entonces, realmente necesito que escuches eso, El. Casi. Es una buena respuesta. La respuesta básicamente es, así que fue una pregunta trampa. Entonces, la respuesta es que no está obsoleto. La mayoría de las personas en la community piensan que fue obsoleto a favor de Apollo Federation, lo cual es un poco cierto. Entonces, Apollo en ese momento creó la unión de esquemas hace mucho tiempo. Y luego en algún momento, se fueron en la dirección de Apollo Federation y decidieron no invertir demasiado tiempo en herramientas de GraphQL. Pero fueron lo suficientemente amables. Y teníamos muchos clientes que usaban la unión de esquemas. Y lo que descubrimos es que Apollo Federation era bueno para muchos casos de uso, pero no para todos. Y aún necesitábamos soportar la unión de esquemas para nuestros clientes. Así que Apollo fue lo suficientemente amable como para transferir las herramientas de GraphQL a nosotros para que las apoyemos. Y hemos hecho mucho trabajo, incluyendo básicamente integrar una bifurcación de la unión de esquemas que estaba siendo desarrollada por Yakov. Puedes encontrarlo en nuestro repositorio. Es uno de los principales mantenedores de la unión de esquemas hoy en día. Está haciendo un trabajo increíble en ello. Y básicamente, desde que asumimos, ha evolucionado mucho. Y creo que en la charla, mencioné los detalles sobre cómo ahora es, no solo no está obsoleto, sino que en realidad es una alternativa muy poderosa a Apollo Federation y cómo en GraphQL Mesh, usamos ambos. Te damos la opción de elegir entre la nueva unión de esquemas y Apollo Federation. Y vemos que en realidad, cuando las personas tienen la opción, cada vez más eligen la unión de esquemas en lugar de Apollo Federation. Así que fue una pregunta trampa. Entonces, la respuesta básicamente es que no, no está obsoleto en absoluto y es mejor que nunca. Así que definitivamente deberías echarle un vistazo si has usado la unión de esquemas antes y fue un dolor, como mencionaron algunas personas, definitivamente deberías actualizar. Y sí. Esa es una respuesta increíble. Muchas gracias por eso. Creo que eso desencadena muchas opiniones de las personas y estoy bastante seguro de que muchos de ellos estaban esperando esto y ahora puedo entender por qué fue una pregunta trampa.

Muy bien, sobre las preguntas y respuestas, creo que un pajarito ha estado dejando algunas preguntas para ti, Uri, desde Discord. Entonces Bastian tiene su pregunta y la pregunta es, ¿Mesh realiza una conversión uno a uno? Por ejemplo, si tengo dos puntos finales que son solicitudes GET, ¿obtendrás dos consultas de eso? Gran pregunta, así que sí y más.

Básicamente, te dará una relación uno a uno, como solo haciendo eso, instantáneamente obtendrás, sí, básicamente dos consultas raíz, pero Mesh también te da la opción de unirlos en uno solo. Y cuando decimos unir en uno solo, puede ser entre esos dos puntos finales, pero también significa que esos dos puntos finales pueden provenir de servicios completamente diferentes. Como uno puede ser REST y otro puede ser gRPC o SOAP u OData. Entonces sí, hace ambas cosas. Y la parte importante aquí es que tienes control total sobre todo el proceso desde la conversión y cómo se ejecutan hasta cómo se fusionan. Así que comenzó con, ya sabes, si es solo una herramienta que hace esas conversiones pero muy rápidamente ahora que muchas personas de la comunidad lo están usando y se está convirtiendo en un producto valioso como una puerta de enlace, necesitas todas esas personalizaciones. Necesitas todo el poder que sea posible. Entonces sí, hoy puedes hacer cualquier cosa con él. Genial, muchas gracias por esa respuesta, fue una gran respuesta. Otra pregunta que tenemos es, ¿puedo especificar fuentes y transformaciones personalizadas usando Mesh? ¿Especificar fuentes personalizadas? Sí, por supuesto. Entonces, las transformaciones, nuevamente, te damos transformaciones listas para usar, pero como las creamos es exactamente cómo puedes crearlas. Puedes crear tus propias transformaciones personalizadas y crear funciones en las que puedas escribir cualquier cosa. Y lo mismo ocurre si quieres crear un nuevo controlador o personalizar un nuevo controlador. Por ejemplo, recientemente tomamos el controlador de esquema JSON, Arda de Guild tomó el controlador de esquema JSON y lo personalizó para que sea un controlador de protocolo FHIR. Entonces está el protocolo FHIR, que es un protocolo médico. Y trabajamos con varios clientes y también lo mostramos en la conferencia FHIR. Y básicamente tomamos un servidor FHIR y creamos automáticamente un SDK de GraphQL mesh para él. Sí, todo es personalizable. Y creo que esta es también la verdadera potencia de Mesh. No solo es personalizable en el proceso de tomar fuentes, convertirlas y fusionarlas, sino que creo que lo más importante es que es personalizable en el lugar donde se ejecuta. Entonces, como dije en la charla, Mesh y schema stitching e incluso si usas, digamos, Apollo Federation, pero en el contexto de Mesh, no necesitas ejecutarlo como un punto central. Puedes, puedes tener un lugar donde todo se fusiona y luego todos consultan esa cosa, ese punto central, pero también puedes ejecutarlo como un SDK y crear una malla, por eso se llama GraphQL mesh. Todas las diferentes fuentes están llamando a ese único gráfico, pero se llaman directamente entre sí. Es una malla de diferentes entidades en el marco. Es una ejecución distribuida. Así que tienes todo el poder para hacerlo. Entonces, sí. Entendido. Respuesta perfecta. Muchas gracias por eso. Y también muchas gracias por unirte a una increíble sesión de preguntas y respuestas. Con esto llegamos al final de esta sesión de preguntas y respuestas, y si tienes más preguntas para Yuri, únete a Yuri en su sala de oradores en chats especiales. Muchas gracias, Yuri. Gracias. Nos vemos allí.