De un servidor Apollo completamente funcional a GraphQL Mesh sin código con la misma funcionalidad

Gracias a nuestro patrocinador, ReactJS. Gracias a nuestros socios, React, y Accelerator. Gracias a nuestros patrocinadores, React, y Accelerator. Gracias a nuestros patrocinadores, React, y Accelerator. Gracias a nuestros patrocinadores, React, y Accelerator. Gracias a todos por venir. Esta masterclass trata sobre GraphQL Mesh. No recuerdo ni siquiera el título, pero supongo que algo sobre GraphQL Mesh. Oh, probablemente el canal de Discord está diciendo eso, sí. Y, sí. GraphQL Mesh es algo que creamos... Quiero decir, lo creamos hace aproximadamente un año y medio, y luego, después de usarlo en producción durante un tiempo, decidimos hacerlo de código abierto. Y lo interesante de la biblioteca es que trae... Surgió de todo tipo de cosas diferentes que nos fueron útiles en todo tipo de escenarios diferentes. Así que la gente siempre ve a GraphQL Mesh como una cosa, pero luego hay otras cinco cosas más que la gente no piensa. Así que hoy espero poder darte una visión general de todo el asunto. Y el taller que tanto yo como Arda de la Guild hemos preparado es como una guía y diferentes formas en las que podrías usar GraphQL Mesh, comenzando por algo muy simple y creciendo hasta convertirlo en una puerta de enlace completa.

Ahora, son talleres de tres horas. Así que tenemos mucho tiempo y la cosa es, doy muchas conferencias pero siempre prefiero simplemente hablar con la gente y recibir muchas preguntas y tener conversaciones en lugar de solo decirte esto es cómo deberías hacerlo. Y creo que esto también es algo que es diferente, que también es quizás mejor para ti porque puedes hacerme preguntas que no puedes hacer si solo me ves en un video de YouTube hablando o algo así. Así que prefiero que me interrumpas tanto como sea posible y hagas preguntas tanto como sea posible. Y espero que esto sea más que solo puedes hacer esto o puedes hacer aquello porque, porque también, espera, déjame, como compartí en, si miras el, si miras el canal de Discord, entonces compartí básicamente el GitHub de la masterclass. Y es de código abierto, ¿sabes? Así que no, puedes hacerlo ahora mismo. Puedes hacerlo más tarde y lo haremos juntos. No te preocupes, lo haremos hoy. Pero hay menos estrés de, ya sabes, tenemos que terminar todo y tenemos que asegurarnos de que todo sea perfecto y cosas así. Puedes hacerlo en tu propio tiempo libre. Y lo que creo que haré ahora es simplemente, tal vez daré una breve introducción a GraphQL Mesh y luego haré como una visión general rápida de la masterclass. Como ya puedes, por cierto, mirarlo. Como si miras el enlace que envié en Discord, hay básicamente una lista de commits. Entonces lo que vamos a hacer es básicamente cada paso de la masterclass será simplemente un commit. Así que puedes ver los cambios entre commit y commit comenzando desde el primer commit y luego avanzando hasta el final. Y eso es básicamente la masterclass. Así que lo revisaré y luego comenzaremos a hacerlo juntos. Ahora, pero nuevamente, lo que espero es que, no sé, también es para mí, como he estado en casa durante demasiado tiempo debido a la situación y COVID y cosas así. Así que en realidad, tener la oportunidad de hablar y hacer que sea más una conversación que simplemente mostrarte cosas es aún mejor para mí y más interesante para mí. Así que realmente quiero que hagas preguntas y plantees tu caso de uso y hables en general sobre GraphQL o cualquier cosa de la que quieras hablar. Así que tal vez, intentaré hacer la introducción breve porque puedes ver mis charlas en línea todo el tiempo o no hay realmente un punto para que mires, ya sabes, solo ver otra charla mía. Así que simplemente lo revisaré muy, muy rápido y luego pasaremos a las cosas reales. Entonces sí, si aún no sabes quién soy o quién es la Guild, somos el grupo de código abierto más grande en GraphQL hoy en día. Construimos un montón de herramientas de las que probablemente hayas oído hablar como el generador de código gráfico que mencioné que básicamente toma tus esquemas y tus consultas y puedes generar cualquier código que desees. Hay un montón de complementos, pero también mucha gente crea sus propios complementos para sus casos de uso específicos. El inspector de GraphQL, como, ya sabes, básicamente verifica las diferencias entre diferentes versiones de tu esquema y se asegura de que no estés rompiendo ningún cambio importante. La CLI de GraphQL, los módulos de GraphQL, las herramientas de GraphQL de las que hablaré un poco. No sé si es probablemente una de las bibliotecas más populares en el mundo de GraphQL. Y estuvo sin mantenimiento durante dos años. Y luego asumimos el control de esta biblioteca, la reconstruimos por completo, y básicamente también recuperamos la unión de esquemas. Pero si pensabas que la unión de esquemas estaba obsoleta entonces no lo está. Hay una versión antigua de la unión de esquemas que Apollo decidió abandonar y optar por la Federación. Reconstruimos la unión de esquemas porque teníamos muchos clientes que todavía estaban usando la unión de esquemas y la Federación de Apollo no reemplazó completamente la unión de esquemas. Así que la asumimos, la reconstruimos. Y hoy en día realmente creemos que es mejor en muchos aspectos es mejor que la Federación de Apollo. Así que si tienes preguntas sobre eso, como sobre la Federación de Apollo, la unión de esquemas y todas esas cosas, por favor pregunta. Como también hablo un poco sobre eso en mi charla principal en la conferencia, pero me encantaría que hicieras preguntas sobre eso porque hay muchos conceptos erróneos allí. Y sí, construimos un montón, muchas herramientas. Y la idea es que, construimos muchas herramientas pequeñas que se mantienen a largo plazo. Creemos que, ya sabes, la comunidad de GraphQL estaba sufriendo un poco durante un par de años porque muchas empresas crearon código abierto y luego dejaron de mantenerlo. Así que somos como, entramos en escena para básicamente mantener esas bibliotecas a largo plazo durante años. Y puedes usar todas esas bibliotecas juntas. Por cierto, es como una gran plataforma, pero no es necesario. Puedes tomar una o dos piezas y simplemente, gradualmente, ya sabes, usar GraphQL. Así que hoy voy a, okay. Así que empecemos. Entonces, ¿cómo debería, así que primero que nada, tal vez haré una pregunta, y algunos de ustedes pueden compartir, tal vez dejaré de compartir la pantalla por un segundo. ¿Todos aquí conocen GraphQL? No sé cómo podemos hacer esto. Como, ¿cómo puedo hacer preguntas? No sé cómo funciona aquí, pero supongo que podemos simplemente escribir en el chat. ¿Hay... Cuántas personas de ustedes... Vale, será difícil hacer estas preguntas así. Así que simplemente continuaré y luego volveremos a tener una conversación completa. Solo terminaré la presentación muy rápido. Compartiré mi pantalla nuevamente.

De acuerdo. Entonces, GraphQL Mesh, la idea de GraphQL Mesh básicamente surgió para mí cuando quería volver a pensar en los conceptos básicos de GraphQL y tal vez encontrar diferentes casos de uso en los que GraphQL podría ayudarnos. ¿Cuáles son los conceptos básicos de GraphQL? Básicamente, podemos describir cualquier dato como un esquema y cualquier base de datos que puede ser una API, llamadas. Puede ser un sistema de archivos en memoria, lo que sea, simplemente podemos crear este esquema que describe los datos y luego podemos consultarlo tal como es.

Veamos un poco cómo sabemos que funciona al describir un esquema, creamos resolvers, de los que hablé un poco, básicamente obtenemos este motor de GraphQL entre el cliente y el servidor. Y luego el cliente, ya sabes, puede comenzar a hacer consultas. Como quiero el ID del usuario y solo quiero el nombre del usuario. Entonces, ya sabes, enviará una solicitud y recibirá el objeto de usuario y luego extraerá solo el nombre de él. Y luego el cliente recibirá, ya sabes, una respuesta con exactamente lo que esperábamos que fuera. Pero luego, ya sabes, si queremos el nombre de los usuarios y los mensajes, entonces nuevamente, el cliente enviará una sola solicitud y el motor de GraphQL buscará al usuario. Luego, en paralelo, obtendremos el nombre y los mensajes. Y luego, para cada mensaje, irá y buscará el contenido. Y tal vez el contenido realmente provenga de una API de terceros o un CMS o algo así. El cliente no lo sabe, no le importa, el cliente solo recibe, ya sabes, una sola respuesta con exactamente lo que se esperaba que fuera. Y, ya sabes, ya conoces todas esas cosas, como recibir, ya sabes, eso significa que enviamos menos datos a través de la red y menos solicitudes a través de la red en comparación con REST. Así que todos hablan de los beneficios de rendimiento de GraphQL y está bien. Pero creo que hay algo mejor, hay más en GraphQL que eso.

Básicamente, ya sabes, si miramos los resolvers, son como pequeñas funciones que reciben un objeto padre. Hacen algún trabajo, cualquier trabajo que queramos y necesitan obtener, devolver un resultado. Y, ya sabes, si construimos esos resolvers y ordenamos todas estas cosas, entonces la función de GraphQL, lo que verás ahora en esta diapositiva es básicamente el funcionamiento interno de la función de GraphQL. Es como un seudocódigo extraño de lo que GraphQL hace internamente. Ahora que estoy pasando por la diapositiva, quiero que pienses, ¿dónde escribes ese código hoy? ¿Cómo haces ese código hoy? Básicamente le decimos a GraphQL, oye, aquí están los resolvers y el esquema y aquí está la consulta que quiero. Entonces, lo que hará GraphQL, tomará el ID, el número dos ejecutará la primera función y nos devolverá el objeto de usuario. Luego irá a buscar las funciones que ya creamos y las ejecutará en paralelo, enviará el objeto de usuario a ambas en paralelo, obtendrá en la primera solo un resultado de cadena, lo colocará en el lugar correcto. Pero de la otra función o resolver, obtendrá tres objetos de mensaje. Entonces, a partir de esos objetos, ahora ejecutará todos esos en paralelo, obtendrá las casillas correctas, como la fecha y el tipo y colocará todos los resultados en el lugar correcto. Todo este trabajo, pero básicamente entender lo que quieres y hacer ese trabajo, básicamente orquestar todo este trabajo y recopilar todos los resultados e intentar hacerlo de la manera más eficiente. Todo este trabajo se hace automáticamente por ti, pero por GraphQL que, en mi opinión, es el núcleo de lo que es GraphQL. Al mirar la consulta de estudio y hacer ese trabajo automáticamente en lugar de código. Por qué, no sé por qué esta diapositiva está aquí, solo un segundo. Oh sí, de acuerdo. Básicamente, esa es una parte de GraphQL, pero como mencioné antes del comienzo de la charla, esos resolvers también pueden tener tipos.

Espero que la mayoría de ustedes hayan oído hablar de los generadores de código de GraphQL para cuando escriben sus resolvers, porque tenemos el esquema, podemos generar las entradas y las salidas. Y eso es genial, pero la cosa es, y ahora tenemos un sistema completamente tipado, ¿verdad? No solo GraphQL automatiza muchas de esas tareas por nosotros, también nos brinda tipos. Todos los resolvers son tipos, conocemos los tipos de la consulta que vamos a recibir. Es muy poderoso. Pero la cosa es, por lo general, ponemos GraphQL encima de sistemas existentes. Como el chico que mencioné antes. Por lo general, lo ponemos encima de un sistema existente en una API REST o algo así. Y la cosa es, cuando llamamos a ese sistema existente, como todos esos diferentes backends, básicamente sigue siendo el mismo código antiguo que hicimos antes. No tenemos tipos para eso. Es una pena. Entonces, la primera razón cuando pensamos en cómo usar GraphQL Mesh fue básicamente, ¿podríamos usar todo tipo de información aquí y tipar esas llamadas? Como nada cambió en la forma en que llamamos a las API antiguas. ¿Podríamos aprovechar algunos de los beneficios de GraphQL y usarlo también allí? Y algunas personas tienen formas de hacerlo. Por ejemplo, algunas personas tal vez dicen, okay, convirtamos todas las API antiguas a GraphQL. Lo cual es posible, o tal vez construyamos pequeñas pasarelas frente a todas esas API antiguas, y eso también es posible. La cosa es, si eres una empresa existente, eso requiere mucho trabajo. Y esas cosas ya tienen suficiente trabajo por sí mismas. Tal vez esto continúa... Sí, lo siento. De acuerdo, continuaré. Si tienes una pregunta, solo grítame y continuaré. Entonces, sí, lo que pensamos es, ¿podríamos aprovechar de alguna manera GraphQL? Lo que queremos de GraphQL, es como un esquema estático y un lenguaje de consulta que automatiza todas las cosas que acabo de mostrarte, pero sobre las APIs existentes que tienes hoy, porque las cosas que tienes hoy, probablemente, ya existen. No es como si no hubiera nada allí. Tal vez use REST con Swagger u OpenAPI, que sigue siendo un esquema y aún puedes entender los tipos de él, o tal vez uses gRPC o SOAP, que incluso está más completamente tipado. Pero incluso si no tienes un esquema, es solo un antiguo punto final de REST. Solo tienes que mirar, digamos, el sistema de registro o los datos en vivo que son ejemplos de datos que provienen de eso, y luego puedes generar a partir de eso un esquema JSON. Entonces tienes algo de información. Entonces, lo que pensamos fue, ¿podríamos tomar esta información y convertirla en GraphQL? Y en las pruebas, hicimos algo similar. No sé si has oído hablar de SOFA, pero SOFA hace lo contrario. Toma un esquema de GraphQL, una API de GraphQL y genera REST a partir de él. Suena extraño, pero ya sabes, hay muchas razones para hacerlo. Quiero profundizar en eso, puedes preguntarme sobre eso más tarde.

Entonces, lo que queremos aquí es hacer lo contrario. Queremos pensar en los esquemas antiguos existentes y queremos generar GraphQL a partir de ellos. Y más tarde, incluso podemos tomar todas esas fuentes de GraphQL y fusionarlas en un solo punto, lo cual usamos como el esquema stitching en la federación de Apollo. Hay mucho de qué hablar también sobre eso. Así es GraphQL Mesh. GraphQL Mesh es básicamente una biblioteca que toma todas esas diferentes fuentes que ves, casi cualquier fuente y las convierte en GraphQL. Y luego también puede fusionar esas diferentes fuentes utilizando herramientas como el esquema stitching y utilizando una federación de Apollo. Entonces, el objetivo es pensar en el mejor tipo de GraphQL pero utilizando tus servicios existentes, para que no necesites construir manualmente todo ese trabajo. Y GraphQL Mesh es... Tenemos controladores para muchas, muchas tecnologías como omitiré esa parte con la demostración porque en realidad lo veremos ahora. Pero tenemos controladores para OpenAPI y Swagger, GRPC. Entonces podemos tomar en el mesh, también podemos tomar por supuesto, GraphQL y servicios federados de GraphQL. Incluso podemos alimentar bases de datos SQL como PostgreSQL, MySQL y SQLite. Si quieres usar SQL Server, avísanos porque queremos algunos casos de uso y personas que nos ayuden a hacer eso. Queremos hacer eso. Y también OData. Por cierto, OData, trabajamos con Microsoft en eso. Microsoft tiene esta cosa llamada Microsoft Graph que básicamente es una API para todos los diferentes servicios de Microsoft, pero está escrito en OData. Así que trabajamos con ellos para convertirlo usando GraphQL Mesh a GraphQL para que las personas puedan consultar GraphQL desde Microsoft Graph. Entonces, nuevamente, la idea era simplemente... Solo queríamos tipos, obtener un SDK, como si estuvieras usando fuentes de datos de Apollo, por ejemplo, la idea era obtener la mejor fuente de datos de Apollo. Para que realmente puedas obtener la experiencia de GraphQL completamente tipada. Pero lo que obtuvimos fue algo más poderoso.

Es un SDK al que realmente puedes enviar consultas e incluso llamar a diferentes fuentes. Obtienes los tipos, pero obtienes la experiencia completa de GraphQL a partir de él. Y mencioné un poco en la charla que también es completamente personalizable. Por supuesto, hay muchas automatizaciones que están sucediendo. Todo se puede personalizar. Porque, ya sabes, puedes hacer una demostración genial, pero cuando lo implementas en producción, hay muchas cosas que quieres personalizar y cambiar. Todo es personalizable y, por supuesto, de código abierto. Sí. Y lo más importante de eso, creo, y eso es lo que quiero demostrar hoy, es que GraphQL Mesh puede tomar todas esas diferentes fuentes, fusionarlas y tener una pasarela muy potente, una fuente a la que todos pueden consultar y obtener la experiencia de GraphQL y el único gráfico y todas esas cosas. Pero la cosa es que eso no es necesariamente lo que siempre quieres. Lo que podemos hacer con GraphQL Mesh en comparación con otras soluciones de pasarela y GraphQL es que también podemos tomar todas esas diferentes fuentes, esquemas antiguos, convertirlos en GraphQL, fusionarlos en un solo esquema y luego generar a partir de ese esquema un SDK. Por lo tanto, ese SDK puede funcionar como una fuente de datos de Apollo en tu resolutor, puede funcionar como un SDK en tu aplicación cliente. Básicamente, puedes obtener un SDK. Por lo tanto, puedes consultar GraphQL en tu aplicación cliente, pero desde tu cliente a todos tus servicios existentes, simplemente puedes usar las mismas API REST. Incluso puedes ejecutarlo, lo que vemos mucho, en otros servicios, como la comunicación de servicio a servicio. Si tienes un servicio de datos o un servicio de aprendizaje automático, ahora ese servicio puede llamar a muchas API diferentes, es un único gráfico, pero eso es por lo que lo llamamos el GraphQL Mesh. Es un service mesh, básicamente se siente como la experiencia del desarrollador, como si todos los datos estuvieran allí en un solo gráfico, pero en producción, en realidad es una malla completa.

Llama directamente a todas esas diferentes fuentes y luego fusiona automáticamente estos datos para ti. Hay muchas cosas, voy a omitir esta parte porque no es tan interesante y hay muchas otras cosas de las que hablar. Y tampoco voy a... deberías ver mi presentación principal mañana porque hay mucho más de qué hablar, pero lo que quiero hacer hoy, primero que nada, es mostrarte cómo hacerlo. Permíteme ir muy rápido a través de la estructura de la masterclass.

Y luego quiero detenerme y hacerte algunas preguntas. Así es como se ve la masterclass aquí. Voy a ejecutarla localmente, pero la idea es que aquí tenemos básicamente un servidor. Voy a mostrarte el código por un segundo. Sí, aquí tengo un servidor de Apollo y, antes de comenzar, te haré algunas preguntas. Si no sabes qué es Apollo server o cosas así, no te preocupes. Pero básicamente vamos a comenzar desde un servidor básico de Apollo. Es un servidor básico de Apollo que llama a fuentes REST. Esa es la forma clásica, si vas al sitio web de Apollo y quieres crear tu propio servidor o algo así, probablemente así te diría que lo hagas. Así que básicamente tienes un servidor, puedes usar Apollo server, lo siento, mi computadora es lenta porque estoy compartiendo la pantalla y todo esto la está ralentizando un poco, pero tenemos un servidor de Apollo, tenemos un par de fuentes de datos de Apollo server. Una es que estamos consultando, básicamente estamos consultando una API REST que nos proporciona todas las cervecerías, como todos los bares y cervecerías y cosas así en todo el mundo. Y la otra forma, y la otra API es básicamente una API Geo. Nos proporciona todo tipo de información sobre ciudades y cosas.

Y lo que realmente queremos, permíteme intentar ejecutarlo. Lo que realmente queremos es, digamos, consultar una ciudad y luego obtener todos los bares o las cervecerías en una ciudad específica. Permíteme mostrarte eso solo por un segundo, solo para que sepamos cuál es nuestro objetivo, sí. Dame un segundo. Nuevamente, mi computadora se está calentando, cerraré esta diapositiva. Así que tengo una API, ya sabes, que nos da ciudades y construí un esquema para eso y tengo una API para cervecerías. Puedo, ya sabes, encontrar cervecerías en una ciudad específica en GraphQL. Sí, tarda un poco porque mi computadora se está calentando, sí. Y solo voy a pasar rápidamente por el código. Lo que está sucediendo aquí es básicamente la forma clásica de hacerlo en GraphQL. Lo repasaré en un segundo, no te preocupes. Tenemos tres horas, tenemos todo el tiempo del mundo. Pero por lo general, lo que haces es construir un esquema. Aquí hay un esquema que describe básicamente, ya sabes, lo que queremos, el esquema que queremos exponer al usuario, como encontrar las consultas por ciudad y eso nos devolverá una matriz de cervecerías. Y luego aquí está toda la información que podemos obtener sobre una cervecería. Y en GraphQL, ya sabes, y luego en los resolvers, lo que hacemos es llamar a una fuente de datos o simplemente una API REST. Y esa API REST es simplemente, ya sabes, es un REST simple, como vamos a obtener cervecerías de esta API pública sobre la que no tengo control. Y algo muy similar está sucediendo aquí en GeoDB. Eso es bueno. Como, eso ya significa que podemos obtener toda la experiencia de GraphQL, ¿verdad? Puedo ir aquí y puedo, ya sabes, obtener autocompletado y puedo, ya sabes, consultar otra cosa, ya sabes, como el teléfono o lo que sea. Y obtendré solo lo que quiero y, ya sabes, todo tipo de otras cosas. No sé qué queremos, como una latitud o algo o el país. Entonces, y obtengo la documentación también, ya sabes, y todas las cosas geniales, pero para eso, ya sabes, obtengo la experiencia de GraphQL, pero tuve que escribir todo esto manualmente, ¿verdad? Tuve que ir y hacer el GET y luego escribir manualmente los resolvers y escribir manualmente el esquema. Y también lo que es más interesante aquí, ya sabes, estoy usando TypeScript aquí, pero esto no está tipado. Como no tengo idea de cuáles son los tipos que voy a obtener aquí. Entonces, esto es básicamente como cualquier cosa y creo que podríamos hacerlo mejor. Así que detengamos esto por un segundo. También cerraré Keynote. Pregunta rápida. Y déjame... Sí. Actualmente estamos trabajando en Node.js y en la parte del backend de GraphQL, ¿correcto? Sí. Entonces, actualmente estamos trabajando en Node.js y en la parte del backend. Pero lo interesante es que todo lo que estoy mostrando aquí, en realidad podrías hacerlo en el cliente. Ese es el punto. Todo el trabajo que te estoy mostrando aquí, que es... Por cierto, todo lo que te mostré aquí todavía es manual. Y te mostraré básicamente cómo... Cada vez más y más automatización y generar los tipos y generar el esquema y cosas así. Ahora mismo, estoy hablando del servidor o básicamente del middleware entre el cliente y el servidor, que es el caso de uso más popular. Pero como mencioné antes en las diapositivas, básicamente podrías hacer lo mismo en todas partes. Como, puedes tomar todas las cosas que te estoy mostrando aquí y simplemente ejecutarlo en el cliente, lo cual vemos... Este es un caso de uso muy, muy popular en general. Como, tengo una charla completa y una discusión completa sobre por qué muchas personas en la comunidad en realidad no están utilizando GraphQL en el backend. Simplemente ejecutan el motor de GraphQL, como GraphQL.js, en el cliente para integraciones fáciles y cosas así. Ese es el plan para hoy. Pero antes de eso, quería... Porque tenemos mucho tiempo y hay muchas horas, y también puedes ejecutar el código tú mismo y hacerlo ahora o más tarde, quiero escuchar un poco. Espero que todos estén abriendo el código. Tal vez también compartiré la pantalla nuevamente para que lo tengamos frente a nuestros ojos. Y quiero escuchar un poco, como algunas preguntas. Primero que nada, este es el primer paso. Sí, acabo de mostrarte cómo hacer eso básicamente. Ese es el código inicial. Pero luego lo que te mostraré es básicamente, primero que nada, ¿cómo vamos a vincular ambos? Básicamente, para poder consultar no solo una consulta para encontrar cervecerías y una consulta para encontrar ciudades, sino que puedo hacer ambas juntas. Básicamente, quiero obtener Chicago y quiero obtener los barrios de Chicago. ¿Cómo lo haría manualmente de la manera regular de GraphQL? Pero luego el siguiente paso después de eso es que voy a usar GraphQL Mesh. Y voy a usar GraphQL Mesh para reemplazar las fuentes de datos. Es decir, en lugar de las fuentes de datos, voy a llamar a un SDK generado. Pero primero que nada, me dará esas funciones con autocompletado, será completamente tipado y se generará por completo, y se generará a partir de los esquemas de los servicios originales. Entonces, todo lo que necesito hacer, y no te preocupes, solo voy muy rápido sobre lo que vamos a hacer. Voy a poner la fuente como el esquema de la fuente, y luego voy a poner la URL y ya está. Y obtendré todas estas cosas para que se generen para mí. Y luego básicamente voy a reemplazar lentamente y cada vez más cosas de Apollo server a GraphQL Mesh. Entonces, no solo usar GraphQL Mesh en lugar de las fuentes de datos, sino también usar GraphQL Mesh básicamente como un servidor, como GraphQL Mesh conectarse a su propio servidor para reemplazar lentamente GraphQL. Puedo simplemente poner las configuraciones aquí básicamente para reemplazar todo el servidor y ejecutar GraphQL Mesh como un servidor, pero luego todavía tengo, en esta etapa, todavía tengo un poco de resolvers que necesito escribir y un poco de código que necesito escribir. El resultado final de la masterclass, si quieres ver la rama principal y simplemente llegar al último commit, aquí básicamente no hay código. Hay dos archivos. Obtenemos el archivo Mesh RC, básicamente todas las configuraciones en un archivo y el package JSON. Eso es todo. Y tenemos un servidor completamente funcional que toma dos fuentes sobre las que no tengo control y puedo consultar todo lo que necesito. Esa es la masterclass.

¿Es tan eficiente como si hubiera sido GraphQL nativo o se vuelve un poco lento como REST? ¿Podemos aprovechar todo el poder de GraphQL tal como funciona? Espero que me esté expresando claramente. ¿Puedes repetirlo pero un poco más lento y tal vez más cerca del micrófono? Sonabas un poco lejos. De acuerdo, de acuerdo. Permíteme intentarlo de nuevo. ¿Supongo que ahora está mejor? Sí, mejor, mejor. Sí, mi pregunta era, ya que solo estamos manteniendo una puerta de enlace frente a la cosa real, el servicio real que estamos intentando ejecutar. Entonces, ¿nos brinda la velocidad que proporciona GraphQL o tiene esta capacidad incorporada de que si es REST, será un poco lento en comparación con GraphQL. Entonces, ¿cómo funciona eso? Sí, buena pregunta. En primer lugar, en cierto modo, en primer lugar, depende de dónde lo ejecutes, ¿verdad? Permíteme compartir la pantalla por un segundo. Entonces, en primer lugar, lo que tenemos aquí ahora mismo es un servidor Node que básicamente recibirá una consulta del cliente. La consulta se ejecutará, digamos, a través de la red. Y eso significa que enviaremos una solicitud a través de la red desde el cliente hasta el servidor, luego el servidor hará cierto trabajo, ya sabes, como todo el trabajo que básicamente hace GraphQL, como la misma diapositiva que te mostré sobre cómo funciona GraphQL, como automatiza esta consulta y se ejecutará, llamará a esta función y también llamará a esta función y esperará automáticamente a que lleguen esas respuestas, luego extraerá solo los datos que necesitas, creará la respuesta que necesitas y la enviará a través de la red al cliente. Ahora, en ese caso, básicamente resolviste, si te importa, ya sabes, menos solicitudes a través de la red y hacer que la solicitud sea más lenta a través de la red y también si te importa hacer que el cliente sea lo más liviano posible, lo que significa que todo este trabajo que este GraphQL está haciendo por ti, básicamente quieres que el cliente solo reciba un resultado, ya sabes, la respuesta tal como quiere renderizarla y eso significa que no necesitas mucho código en el cliente, entonces sí, básicamente, obtienes un mejor rendimiento porque ahora todo son compensaciones, ¿verdad? Entonces significa que a través de la red, ya sabes, será mucho más rápido. Pero aún así significa que ahora tienes esta puerta de enlace, esta puerta de enlace de GraphQL, sin importar la tecnología que se esté utilizando, realiza cierto trabajo, ¿verdad? Incluso si el código es automático, aún realiza cierto trabajo. Ahora, nuevamente, puedes tomar todo ese trabajo, todo ese código que te estoy mostrando aquí y básicamente poner ese mismo código en el cliente. Y lo que sucederá entonces si haces eso, a través de la red, aún obtendrás múltiples solicitudes y múltiples respuestas, ¿verdad? Porque el cliente llamará directamente a esos recursos pero significa que el código esperará a que lleguen y el código extraerá solo los campos que necesitas y todas esas cosas son automáticas. No necesitas escribir ese código. Así que eso ya es muy poderoso. Ahora, lo que vamos a hacer aquí es que vamos a tomar lentamente ese código, esos resolvers y las fuentes de datos y todo y convertir eso en GraphQL Mesh, como convertir esto en código automático y eso no va a cambiar nada. En términos de eficiencia, es lo mismo. Incluso podemos hacerlo un poco más eficiente pero eso es un caso de uso más avanzado pero básicamente es lo mismo. No necesitas escribir código. Entonces, la diferencia entre el rendimiento, si esa es tu pregunta, la diferencia entre el rendimiento entre esta parte y esta parte, no hay diferencia. Aquí no escribimos ningún código pero es tan eficiente, si no más eficiente que esta parte. Así que eso es algo muy poderoso. Espero que responda tu pregunta. ¿Responde a tu pregunta? Genial. Genial, más preguntas. Sí. Hola, gracias por cierto. Es muy interesante. Tengo en realidad dos o tres preguntas. Así que tal vez solo las haga todas juntas. Espero que no sea demasiado. Sí, está bien. Y solo diré todas las demás. Mientras tanto, intenta clonar el repositorio e intenta ejecutar el primer paso y luego intenta comenzar a hacerlo. Así que tal vez ya comiences a hacer esas preguntas, como obtener más y más preguntas mientras avanzas. Pero sí, por favor continúa. Perfecto, gracias. Sí, entonces la primera, ¿también puedo usar GraphQL Mesh para consultar una API RESTful como Airtable o Ghost? No sé si estás familiarizado con eso, pero parece que ese es el caso. Sí, solo para responder a tu pregunta antes de que continúes con la siguiente. Entonces sí, la respuesta es, sí, GraphQL Mesh puede consultar cualquier API. Y te mostraré, una de las cosas que voy a mostrar hoy, una de las fuentes que estamos consultando, creo que es, déjame ver por un segundo, solo para asegurarme. Una de las fuentes que estamos consultando hoy, déjame encontrarla. La API Geo tiene un esquema Sweger. Así que es muy fácil. Tomamos el esquema Sweger y lo generamos. Pero la API OpenBrewery, la otra API que estamos consultando, no tiene ningún esquema. Solo tiene un sitio web en el que puedes, ver ejemplos, tal vez sean correctos, tal vez no. Entonces, lo que estamos haciendo allí es básicamente, tomamos un par de ejemplos, JSON que obtuvimos del, o del sitio web de ejemplo, o simplemente enviamos el código y lo que obtuvimos, lo alimentamos en GraphQL mesh, GraphQL mesh convierte eso en un esquema JSON y convierte el esquema JSON en GraphQL. Entonces eso significa básicamente que se puede consultar cualquier API. Tenemos, por cierto, déjame, sabes qué, también agregaré otro, enlace útil mientras hablo, agregaré otro enlace útil para una publicación de blog muy interesante que básicamente te muestra cómo puedes tomar cualquier GraphQL, cualquier, lo siento, cualquier API REST y convertirla automáticamente utilizando esta técnica. Básicamente, la idea es que no tienes ningún esquema. Entonces, ya sabes, no sabes casi nada sobre esa API REST excepto la URL y puedes migrarla a GraphQL. Lo estoy poniendo ahora en el, en el chat. Así que espero que haya respondido tu pregunta. En el GraphQL, solo mencionaré un par de cosas más. Como en el repositorio de GraphQL en sí, también agregaré el enlace. Hay muchos ejemplos diferentes. Entonces está la API de Stripe, hay como, simplemente, las personas están contribuyendo lentamente más y más APIs a mesh. Así que hay toneladas de APIs, pero nuevamente, puedes elegir cualquier API y simplemente comenzar a editar. Espero que haya respondido tu pregunta. Sí, definitivamente. Sí, lo es. Hoy en realidad estamos haciéndolo manualmente y por lo tanto, por eso, GraphQL mesh es muy, muy interesante, sí. Sí. Entonces, ¿cómo lo haces cuando, cuando dices que lo haces manualmente, te refieres a que consultas esa API y luego escribes el esquema manualmente, ¿verdad? Puedes escribir el esquema de GraphQL manualmente. Correcto. Correcto.

Exactamente. Sí. Probablemente de la misma manera en que comienzas a demostrar con las fuentes de datos. Exactamente. Sí. Y luego la segunda pregunta, tal vez también la tercera que está relacionada, también me pregunto si es posible agregar algún tipo de middleware entre el código generado y el resolver, como para manipular los datos. Y también la tercera, que está relacionada, también es como ¿qué pasa con el almacenamiento en caché y dónde exactamente también entra en juego?

Esa es una gran pregunta. Debido a que la masterclass es corta y no lo demostramos, pero ya voy a poner esas partes de la documentación. Así que lo mencioné un poco en mis diapositivas rápidas, pero voy a compartir, en primer lugar, esto, lo voy a poner nuevamente en el canal de Discord, si alguien no sabe sobre el canal de Discord o dónde está, avísenme o alguien más puede publicarlo en el chat. Pero lo que puse aquí básicamente es una lista de muchas transformaciones diferentes. Entonces, básicamente, puedes controlar cada parte de ese paso automatizado. Así que digamos que obtienes algún esquema, obtienes algún esquema y luego se está generando, y digamos que tal vez ese esquema no es correcto, o tal vez, ya sabes, porque sabemos que los esquemas, los esquemas de swagger no siempre están actualizados, como en la vida real, o tal vez está actualizado, pero quieres que la salida se vea diferente. Entonces, en el paso de la transformación en sí, es completamente enchufable y puedes controlar completamente todo. Entonces, lo que enumero ahora es básicamente solo una transformación de ejemplo que puedes renombrar cosas. Y si vas allí, verás que hay muchas otras, hay gráficos y todo tipo de cosas así. Pero también hay almacenamiento en caché. Entonces, también puedes crear, básicamente, una transformación de caché en cada una de esas cosas generadas. Así que déjame poner eso también. Básicamente, GraphQL Mesh en ese caso puede actuar como una puerta de enlace de API completa, ¿verdad? Y tienes control total. También puedes, lo que verás en las etapas posteriores de la masterclass aquí, es que estoy agregando resolvers adicionales. Entonces estoy usando las dos fuentes, pero luego estoy agregando más. Puedo agregar resolvers personalizados y esquemas personalizados en mi puerta de enlace. Sí, espero que ayude, responde a tu pregunta. Pero si hay más, sigue preguntando. Muchas gracias.

De acuerdo, genial. Vi que alguien escribió un mensaje en texto. Tengo una API REST que utiliza JWT para la autenticación y el token se envía con la solicitud y limita lo que se devuelve al usuario. ¿Qué necesitaría cambiar para incluir la API en mi GraphQL Mesh?

Entiendo. Sí, buena pregunta. Entonces, en la configuración de Mesh, simplemente puedes configurar encabezados como antes. Como todavía quieres obtener el token JWT, quieres, digamos, agregarlo en el encabezado o algo así y luego enviar la solicitud. Entonces, Mesh es completamente configurable para eso. Puedes agregar encabezados y hacer lo que quieras. Sí, básicamente estás haciendo lo mismo. La API REST seguirá obteniendo el mismo token JWT. No hay razón, no hay razón para cambiar eso. Y por cierto, eso también es algo así como la mejor práctica si escribes GraphQL. Muchas personas, cuando escriben GraphQL, piensan que tal vez ahora deberían mover todas las partes de autorización dentro de GraphQL y necesitan anotar su esquema. Creo que eso no es necesariamente una buena práctica porque básicamente quieres que tus fuentes controlen la autorización y quieres autenticar antes. De todos modos, si observas la solicitud que llega, quieres autenticar la solicitud y luego pasarla a GraphQL. GraphQL no debería importarle. Solo toma ese encabezado y simplemente pásalo y luego la autorización ocurrirá en las fuentes mismas como antes. Entonces, digamos que habilita otra cosa realmente genial en GraphQL, lo cual es, digamos que en una fuente tengo permiso y en otra fuente no tengo permisos. Podrías obtener resultados parciales, a diferencia de REST, que simplemente fallará toda la solicitud. En mi opinión, esa es la mejor práctica o algunos conceptos erróneos que las personas tienen sobre la autenticación y autorización en GraphQL. Esa es una muy buena pregunta. Sí, creo que Aleksandra está aquí. Oh sí. De acuerdo. Más preguntas. Hola. Sí. Tengo una pregunta rápida. ¿Es posible que el servidor esté al tanto de estas consultas auto-generadas para poder usar consultas persistentes en el lado del servidor?

Esa es una buena pregunta. Cuando dices consultas auto-generadas, ¿te refieres cuando usas el SDK? Sí. Esa es una buena pregunta. Creo que actualmente no tenemos algo que lo haga automáticamente, pero es bastante fácil de hacer. En general, por cierto, una cosa que queremos hacer ahora mismo es como el soporte actual, las herramientas actuales en la comunidad para las consultas persistentes están como a medio hacer, no sé, en mi opinión. Así que en realidad estamos construyendo dos clientes que acaban de comenzar a construir algo que lo hace un poco más fácil. Hay Apollo automatic persistent queries y todo tipo de cosas así. Creemos que hay mejores herramientas para eso. Vamos a abrir un registro de código abierto que podría recibir servicios GraphQL, servicios REST, servicios SOAP, luego usar las capacidades de mesh para convertir todo eso y luego ver todo eso como una API GraphQL, solo para que puedas explorarlo. No significa que necesites consultar todo desde allí, solo para que puedas tener una mayor visibilidad de todos los datos en tu red. No lo mencioné para responder. No dije eso para responder a tu pregunta. Para tu pregunta, creemos que ese registro también ayuda en términos de registrar todas las consultas diferentes que deseas tener, registrarlo en algún lugar y luego generar los IDs de las consultas persistentes y cosas así. Así que solo para decir que toda la herramienta está alrededor de eso, tenemos algunas herramientas internas que vamos a abrir que lo harán más fácil. Para tu pregunta sobre tomar las consultas generadas por mesh, es una buena idea. Y quiero decir, si puedes abrir un problema en GraphQL mencionando eso, sería realmente genial porque es muy fácil de hacer. Y también este código que genera todas las consultas posibles desde un tipo específico o algo así, queremos moverlo para que las personas puedan usarlo incluso sin usar mesh. Es una buena idea. Eso sería bueno. Sí, gracias por la pregunta. Veo más preguntas en el texto. Mencionaste antes que podrías querer cambiar de GraphQL a REST. ¿Cuándo y por qué necesitarías hacer eso? Oh, pregunta interesante. Se llama SOFA, lo que mencioné. Permíteme poner el enlace solo para, encontrar el enlace mientras hablo. Pero la idea de SOFA fue que lo tuve hace mucho tiempo, creo que incluso hace dos años o más, y la idea fue que GraphQL, en mi opinión, es como todos hablaban, ¿debería usar REST o GraphQL? ¿Qué es mejor y blah, blah, blah? Y lo que pensé cuando miré la tecnología principal, pensé, bueno, GraphQL en términos de la información que tienes es básicamente como un superconjunto de REST. Como tienes el esquema y tienes los datos y solo, puedes pensar en ello, los controladores se ejecutan automáticamente o se ejecutan automáticamente y tienes una consulta. Pero si piensas en el punto final de REST, básicamente hay una consulta, ¿verdad? Como hay algo que se devuelve, solo que nadie te dice que es una consulta. Así que pensé, ¿puedo cambiar ese debate? ¿Puedo mostrar que GraphQL es como puede hacer todas las cosas que REST puede hacer pero más? Así que por eso creamos SOFA. Acabo de abrir, acabo de compartir la publicación del blog en el canal nuevamente.

Entonces, lo que hace SOFA es tomar el esquema, genera automáticamente llamadas REST que son similares a lo que acabamos de hablar, lo que hace Mesh. Y mira los tipos y genera las posibles consultas, como la consulta anterior, todos los diferentes campos de un tipo y simplemente genera una API RESTful. Entonces, para cada tipo, obtienes un punto final que consulta todos los diferentes campos. Eso lo hace automáticamente. Solo una línea de código y obtienes la API REST sobre tu API GraphQL existente. La razón por la que quieres hacerlo es porque, la razón por la que lo creamos fue porque trabajábamos con una gran aerolínea y las partes web se movieron a GraphQL, pero las partes móviles pensaron que GraphQL simplemente no era interesante en absoluto. Pero aún queríamos mantener una única puerta de enlace. Básicamente, expusimos REST para los temas móviles sin que ellos supieran que en realidad estaban utilizando GraphQL. Y lo más genial de esto fue cuando querían personalizar, como una cosa que sucede cuando tratas con REST y estos temas vienen y dicen: `Oye, ¿podrías personalizar, podrías cambiar el punto final o darme un nuevo punto final para darme un poco de estos datos y un poco de esos datos?`. Entonces, lo que hicimos fue simplemente crear una nueva URL y adjuntar una consulta a ella. Y eso es todo, obtienes un nuevo punto final personalizado. Así que, en lugar de tardar una semana entera en crear un nuevo punto final, ahora solo toma cinco minutos. Eso es lo que hace SOFA, básicamente es lo contrario, convierte GraphQL en REST. Este juego de ajustar REST a todas las diferentes fuentes es muy interesante para nosotros. Aprendimos mucho sobre otros protocolos, como OData, que es un protocolo muy interesante. Entonces, JSON schema, hay muchos protocolos interesantes y jugar con ellos realmente te da una perspectiva diferente de lo que es posible y sí, espero que responda la pregunta. Genial. ¿Cuáles son las capacidades de caché de Mesh? Creo que acabo de responder a la pregunta de Liron. También compartí el enlace en Medium. Entonces, puedes verlo, básicamente puedes configurar qué campos, como puedes configurar las claves de caché. Puedes invalidarla, puedes usar TTL, sí, hay muchas, muchas opciones diferentes allí. Hay muchas opciones, me gustaría, sería genial si pudieras echarle un vistazo y decirnos si nos perdimos algunas capacidades o algo en la caché que puedas necesitar. Pero básicamente la idea es que hoy en día, Meshed también se utiliza como una puerta de enlace completa con muchos de nuestros clientes, por lo que es necesario admitir todo eso. Nuevamente, al comienzo de la masterclass, acabamos de comenzar a usar Meshed como un SDK, como una mejor fuente de datos de Apollo, pero también se ejecuta como una puerta de enlace completa con todas las capacidades de caché. Y en realidad, incluso puedes definir esas cosas de caché incluso si generas un SDK, pero sí, espero que responda la pregunta.

De nuevo, tenemos, creo que incluso todavía quedan dos horas para pasar por todos esos pasos, así que quiero más preguntas. Si tengo una pregunta. Sí. Bueno, quiero usar un GraphQL Mesh, pero el problema es así. Los servicios detrás de él, como puedo tener alguna API REST y algunos otros GraphQL y tal vez una base de datos. Todos devuelven el mismo esquema. Necesito un discriminante en el lado del cliente, como digamos un ID de inquilino, y la lógica me dará algo así como, si tienes este ID de inquilino, te redirigiré al uno de GraphQL. Si este es el ID de inquilino GraphQL dos o REST tres o directamente a la base de datos. ¿Es esto posible? ¿Cómo lo hago? Porque necesito exactamente la misma consulta y todos ellos deben tener el mismo esquema exacto, pero hay tres servicios y cada servicio es para un inquilino diferente. Entiendo. Y la pregunta es, ¿quieres exponerlo al cliente como un solo esquema o como esquemas... Sí, no, no, no. Necesito un solo esquema, por lo que el cliente no necesita saber que ha sido redirigido. Simplemente algo en su autenticación o algo detrás de escena que dice, oh, eres este inquilino, así que irás allí. No importa lo que quieras o lo que sepas, nunca verás los otros. Sí, sí, sí. Esa es una muy buena pregunta. En primer lugar, la razón por la que pregunto si quieres exponerlos de manera diferente es porque muchas veces hay conflictos entre las diferentes fuentes. Y luego la pregunta es qué hacer. Y todo es posible. Es solo una cuestión de lo que prefieras. Por ejemplo, lo que compartí fue que puedes usar transformaciones personalizadas y las transformaciones pueden hacer cualquier cosa. Por ejemplo, puedes agregar un prefijo a cada uno de esos y luego tienes... Aunque hay conflictos, es básicamente como espacios de nombres o algo así. Pero eso funciona para algunos casos de uso, pero para tu caso, no es así. Pero solo menciono que es posible para otros. En tu caso, lo que quieres es básicamente algo que se ejecute delante de todos ellos, como un middleware o algo así que luego los redirija a la fuente correcta. Entonces hay algunas formas de hacerlo. Sugeriría mirar la composición de resolvers, básicamente puedes definir algunas funciones o es como un middleware que se ejecuta delante de todos ellos. Y como se ejecuta cada vez antes de que se llame a cada Resolver, puedes ejecutar cualquier llamada arbitraria allí. Entonces, básicamente puedes escribir algún código que tome del contexto, básicamente el SDK correcto o la fuente correcta y simplemente pase la consulta a esa fuente. Entonces sí, definitivamente es posible. Si necesitas más ayuda con eso, como incluso puedo hacer una reproducción o un ejemplo, puedo entrar y hacer algunas PR si no puedes resolverlo, pero definitivamente es posible.

De acuerdo, entonces, ¿esto es posible con GraphQL Mesh? ¿Puedo configurarlo con, qué necesitaría poner en GraphQL Mesh para decirle que use este discriminante y simplemente elija una fuente? Entonces, lo que imagino que estás haciendo y creo que puedes comenzar a hacerlo, digamos en GitHub y puedo unirme y ayudarte si te quedas atascado, es que primero pondría en Mesh todas esas tres fuentes. Generaría el esquema y luego usaría la composición de resolvers para decirle a Mesh qué SDK usar para cada consulta. Es un poco complicado, no es muy sencillo, así que en realidad sería genial si puedes, no sé si puedes, si tienes la opción, si puedes crear una reproducción simple, como una aplicación simple que haga algo similar y luego puedo ayudarte a hacer eso. De acuerdo, gracias, intentaré ver si puedo hacer algo. Sí, por cierto, compartiré mi GitHub para que las personas, en mi Git, en mi GitHub, también está mi correo electrónico privado. Entonces, si quieres contactarme o si quieres, y por supuesto, siempre puedes abrir un problema en el repositorio de GraphQL Mesh, pero sí, lo comparto en caso de que alguien quiera. De acuerdo, gracias. Sí, de nada, más preguntas si tienes. De acuerdo, daré un minuto más para que la gente haga preguntas y luego podemos comenzar a pasar por los pasos. Nuevamente, puedes comenzar a hacer esos pasos ahora mismo, simplemente clona el repositorio y hazlo. Estoy compartiendo, pero por favor sigue haciendo preguntas. Quiero que sigas haciendo preguntas. Eso es mejor para mí. De acuerdo, así que lo que tengo aquí. De acuerdo, así que lo que tengo aquí es básicamente el primer paso, si clonas el repositorio y luego revisas este commit, este primer commit, eso es donde quiero que estés. Ahora y quiero que luego, ahora clónalo, revisa estos pasos, luego ejecuta yarn para instalar todo y ejecuta yarn start para ejecutar esto. Ahora hazlo de nuevo. Y solo para pasar rápidamente por la configuración. Y nuevamente, si esto es, digamos, nunca has ejecutado un servidor GraphQL antes y no entiendes lo que está sucediendo aquí, dime, por favor, detenme y haz preguntas, no hay preguntas tontas en absoluto aquí. Entonces, lo que estoy haciendo aquí es que instalé básicamente Apollo Server, que por cierto, solo mencionaré, estoy usando Apollo Server aquí porque es la opción más popular, pero no es la mejor opción, en mi opinión. Entonces, si estás usando Node, digamos, y quieres construir un servidor GraphQL, deberías mirar, déjame mostrarte dónde... Por cierto, ahora voy a graphql.org. Hemos reconstruido graphql.org, lo hemos construido en Gatsby ahora y cambiamos las secciones de código. Ahora está mucho más organizado y puedes ver que se organiza por lenguajes, por lo que si vas a JavaScript, tenemos la implementación del servidor, las bibliotecas de cliente y las herramientas. Y también los ordenamos por su popularidad y cómo se mantienen, y cosas así. Entonces, Apollo Server es una de las opciones más populares. Pero en mi opinión, actualmente la mejor... Pero no se mantiene bien, para ser honesto. Las dependencias son muy antiguas y hay toneladas de problemas, problemas abiertos y PR abiertas, y simplemente no están muy activos allí. Pero en mi opinión, la mejor opción actualmente es esta, GraphQL Helix. Compartiré el enlace contigo, aunque puedes encontrarlo tú mismo.

Y me pregunto si aquí hay un enlace al artículo del blog, porque el artículo del blog... Sí, hay un enlace al artículo del blog. Lo compartiré aquí. Es un servicio de GraphQL bastante nuevo, pero es como si construyera el servidor de GraphQL de mis sueños, eso es lo que usaría. Y nuevamente, si hiciera el trabajo manualmente, internamente en GraphQL Mesh, por cierto, acabamos de cambiar de ExpressGraphQL a GraphQL Helix. Así que sí. Solo menciono que si estuvieras comenzando desde cero y tienes la opción de cambiar, hoy en día me cambiaría de Apollo Server a GraphQL Helix. Pero Apollo Server sigue siendo probablemente la opción más popular, así que es lo que vamos a usar ahora. Instala Apollo Server, que básicamente nos da la opción de, tomamos un servidor y podemos enviar definiciones de tipos y resolvers desde él, y luego ejecutará el servidor. Así que eso es genial. Eso es Apollo Server. También vamos a instalar GraphQL-Tools Merge. Lo que hace GraphQL-Tools Merge es que muchas veces lo que quieres es... Entonces, la gente piensa que podrías, digamos, comenzar a escribir tu esquema de GraphQL. Sí, pero quieres separarlo como aquí. Básicamente queremos organizar mejor el código, queremos separar el esquema en responsabilidades. Entonces, algunas personas piensan que necesitas usar Apollo Federation para eso o algo así, pero no es necesario. Simplemente puedes poner esos dos, los esquemas y los resolvers en dos carpetas separadas y decirle al equipo o a la persona específica, tú eres responsable de esta parte y tú eres responsable de esta parte. Y luego necesitas fusionarlos juntos, por lo que puedes usar GraphQL tools merge. Eso significa que en tiempo de compilación, tomará todos los diferentes tipos y todos los diferentes resolvers y los fusionará en uno solo y luego los enviará a Apollo Server o cualquier otro servidor que estés utilizando. Así que eso es simplemente, ya sabes, algunas personas piensan que para separar tu código entre diferentes lugares, necesitas usar Apollo Federation o algo así o schema stitching, no lo necesitas, puedes hacerlo en tiempo de compilación y eso en realidad es mucho mejor en términos de rendimiento que Apollo Federation o schema stitching. Así que solo para que lo sepas, y si quieres crear esa separación aún mejor, también existe GraphQL modules, que creará la misma separación que acabo de mostrarte, pero también separará el contexto y utilizará la inyección de dependencias para asegurarse de que haya una separación realmente buena. Pero nuevamente, en tiempo de compilación, los fusionará todos juntos. Acabamos de lanzar la versión 1.0, por cierto, GraphQL modules, así que también lo agregaré aquí en caso de que te resulte beneficioso. Ok, eso es GraphQL tools merge entre piedras. Luego, por supuesto, queremos usar GraphQL porque ese es el caso. Estamos usando TypeScript y usamos TSO para ejecutarlo, pero nuevamente, la configuración de TypeScript no importa aquí. Puedes usar la configuración que desees, TypeScript o JavaScript, nuevamente, no importa. Pero lo que hacemos aquí es usar Apollo data sources rest porque Apollo, esta es la forma más común hoy en día para que las personas llamen a fuentes de datos REST. Luego veamos el código. Comencemos, digamos, con GeoDB. Primero, escribimos manualmente el esquema aquí. Escribimos, ya sabes, encontrar ciudades y tenemos la respuesta y luego aquí está la cosa. Y todas esas cosas las configuramos manualmente. Si quieres que lo haga más despacio o tienes preguntas, por favor pregúntame, pero lo estoy haciendo rápidamente porque, ya sabes, todos los tutoriales de GraphQL por ahí te mostrarán cómo hacerlo. Pero ahora me tienes aquí. Así que por favor haz preguntas si lo necesitas. Y luego en los resolvers, sí.

Solo una pregunta rápida. Estaba utilizando GraphQL Merge porque básicamente estaba extrayendo de un microservicio la definición Swagger y generando el esquema GraphQL a partir de ella. Luego, no pude usar el archivo generado en bruto porque no quería exponer todos los tipos al cliente. No pude encontrar una forma de exponer solo algunos de ellos y ocultar los que no... Oh. Interesante. Entonces, quieres... ¿Estás hablando de GraphQL Mesh ahora o simplemente de GraphQL regular? Solo el merge. Quiero decir, no realmente con el merge, pero supongo que estaba usando el merge para fusionar automáticamente esos esquemas de GraphQL generados con los míos. Interesante. Entonces, lo que has hecho, si entiendo correctamente, es algo intermedio a lo que estamos haciendo aquí. Tenías un esquema Swagger. Generaste esto, como generaste un esquema a partir de él, pero luego manualmente eliminaste algunos campos o renombraste algunos campos. Correcto. Y luego lo hiciste. Entiendo, y la razón por la que lo hiciste es porque, digamos que generaste esto y también generaste este esquema. Y luego querías fusionarlos en un solo esquema para exponer, pero querías hacer una lista blanca o una lista negra de algunos de ellos. Sí. Correcto. Esa es una pregunta interesante, de hecho, porque en GraphQL Mesh te damos la opción de hacerlo. En GraphQL Mesh, tienes las transformaciones de esquema, pero nunca pensé en usarlo en el contexto de GraphQL Tools para hacerlo en tiempo de compilación con la lista blanca y la lista negra. Y eso es interesante. Podríamos hacerlo fácilmente, muy fácilmente. Entonces, tal vez incluso, quiero decir, GraphQL Tools se usa. Entonces, tal vez lo tengamos y ni siquiera lo sé, pero es muy fácil de hacer. Así que nos llevaría un par de minutos incluso. Entonces, lo que sugiero es que abras, en lugar de hacerlo manualmente, no hay razón. En realidad, lo que querrías aquí es tener algo así como, ya sabes, tomar el merge y tal vez agregar alguna función aquí que sea como, puedes decir, ya sabes, lista blanca. Y luego no sé, podrías hacer algo como, ya sabes, asteriscos o algo así o alguna regla para filtrarlos. Y luego está bien. Sí. Es una idea realmente genial y creo que es muy útil. Y si no lo tenemos, entonces, por favor, abre el... Espera, creo que hay personas esperando para ingresar, cómo lo hago... De acuerdo, de todos modos, abre un problema para eso y nos encargaremos. Así que no necesitarás hacerlo manualmente, no hay razón para hacerlo manualmente. De acuerdo. Sí. Gracias. Lo haré. Sí, sí. Es una idea genial. Gracias. Sí. De acuerdo.

Solo una pregunta rápida. Mencionaste las diferentes herramientas de Apollo que podríamos usar y mencionaste que usarías Apollo Helix, pero esto es solo para soluciones backend, ¿verdad? Sí, sí. Ahora estoy hablando de la implementación del servidor. Sí. Entonces, el servidor... Porque ahora lo que vemos aquí es que ahora estamos usando Apollo Server. Básicamente, no estoy hablando en absoluto del cliente. Nuevamente, mencioné que básicamente si elimino esto y esto, teóricamente, todo lo que ves aquí puede ejecutarse en el cliente. Sí. Entonces puedes tomar GraphQL y GraphQL Tools, ejecutarlo en el cliente como si fuera un servidor, pero aquí solo estoy, solo quería mencionar que creo que Helix está mucho mejor mantenido y hay muchas características nuevas geniales en GraphQL de las que hablaré en la próxima clase que Apollo Server no admite y Helix sí, así que sí.

Esto es solo para el backend de Node.js, ¿verdad? Sí, sí, buena pregunta. Aquí estamos hablando ahora de la implementación en JavaScript. La pregunta final es respecto a esto, el frontend, el lado del cliente y el lado del servidor son completamente independientes entre sí. Podemos usar cualquier tecnología en cualquiera de los lados sin afectarse mutuamente, ¿verdad? Exactamente, sí, exactamente. Básicamente, no es solo el frontend y el backend, incluso la parte de la consulta y la ejecución, ¿verdad? Porque en realidad podría ejecutar esto no entre la red, simplemente puedo ejecutar todo esto en el cliente y nuevamente tengo una o está en un servicio y luego tengo la parte de la consulta y tengo la parte de la ejecución. Y es por eso que en Mesh lo usamos mucho en entornos que no son JavaScript en absoluto. Creamos mallas y SDK para aplicaciones Java, para aplicaciones .NET, cosas así. Entonces, en ese caso, la ejecución será lo que elijas hacer en el backend en este escenario. Y en el frontend, lo que hagas será la parte de la consulta. Sí, no tenemos demasiados ejemplos de código abierto para eso porque no tenemos muchos casos de uso de ese tipo, pero si tienes, por ejemplo, un caso de uso así, hablemos y creemos juntos un ejemplo público. Creo que a mucha gente le resultaría útil. De acuerdo. Creo que es una buena pregunta. Sí, vi que había un chat y tal vez me estoy perdiendo cosas en el chat. Déjame revisar. Sí, de acuerdo. La gente está agradeciendo que me cubras. De acuerdo. Entonces, nuevamente, lo que, solo iré muy rápido. Entonces, escribimos esto manualmente, luego creamos un resolver, ¿verdad? Y este resolver no tiene tipos. Nuevamente, si tienes un resolver en Node.js y usas TypeScript, esta cosa, la consulta, como esto, lo siento, esta cosa en find cities, no tiene tipos. Ves, todo es any, any, any, any, y el tipo de retorno también es any para eso. Lo mencioné antes. Deberías usar, no voy a, nuevamente, no estoy hablando de esto hoy, pero si estás haciendo este código así hoy, deberías ir al generador de código GraphQL y usar el complemento de firma de resolvers. Y el complemento de firma de resolvers, lo que ves aquí es que obtienes el esquema y luego básicamente tipa esos resolvers. Entonces, automáticamente obtendrías esas funciones, la ruta antigua, los argumentos, el contexto y el tipo de información y el valor de retorno también estarían tipados. Así que solo para que lo sepas, es una herramienta muy popular y probablemente la usemos. Pero hay más cosas que no están tipadas aquí. Esta es una función como, ya sabes, find cities. Esta es la función del resolver y este es el contenido de esa función. Lo que hago, voy a las fuentes de datos del contexto porque así es como, ya sabes, trabajas con las fuentes de datos de Apollo Server. Y creé una fuente de datos de API de Geo DB que tiene una función llamada find cities. Nuevamente, en esa función, verás que no hay tipos. Básicamente, no tengo, si cometo un error aquí, estoy llamando a la API REST y ni siquiera tiene las cosas que necesito.

Lo sabría hasta que entre en producción. Por cierto, esta es la fuente de datos, voy aquí. Nuevamente, es solo una función manual que creo, manualmente la clase Geo DB API, de la fuente de datos de la misma función que creamos. Le doy la mejor URL y luego puedo hacer get o post y le doy, ya sabes, algunos argumentos. Y en este caso, es un prefijo de nombre. Por cierto, puedes ir a Geo DB si quieres ver las fuentes que estamos creando aquí, por cierto, puedes ir a esas URLs. No necesito compartirlas contigo porque las tienes en el código. Pero sí, esas son las fuentes, como Geo DB, no recuerdo. Incluso si lo buscas en Google, obtendrás esto. Y lo mismo ocurre con la Open API, Open Brewery API. Abriré esto también aquí. Así que luego puedes averiguarlo. Sí, eso es todo. Entonces, nuevamente, todo funciona, puedes ver, tengo un servidor GraphQL en funcionamiento. Tengo la documentación que se basa en el esquema manual que creé, puedo buscar en los documentos y hacer consultas. Así que puedo buscar y encontrar ciudades. Y nuevamente, puedo escribir algo aquí como longitud o algo así, y en este caso, Chicago y obtengo esto. O si escribo aquí, no sé, Tel Aviv o algo así, obtengo Tel Aviv. Así que eso está bien. Y nuevamente, estoy enviando esta consulta desde un cliente, va a mi servidor, mi servidor analiza esto, llama a la fuente de datos, todo está bien. Ahora, queremos pasar al siguiente paso. Ahora, el siguiente paso, solo voy a revisar esto y luego vamos a ver los cambios. Y déjame ocultar esto, veamos si podemos... Nada controla. Veamos si podemos mostrar esto. Si esto es más pequeño, entonces podemos aumentar esto. Me pregunto si puedo hacer esto más grande y si no es más grande. También puedo abrirlo aquí, ¿verdad? Déjame levantarlo para que sea más fácil de ver. Y luego también veremos todo lo que vemos en el código en sí. También voy a volver a ejecutar el servidor. De acuerdo, veamos qué vamos a hacer aquí. Esto es nuevamente, todavía GraphQL, todavía no tiene nada que ver con Mesh. Lo que estoy haciendo aquí es que quiero conectar. Hasta ahora, consulté cada una de esas APIs por separado. Tengo find cities y tengo find breweries y funcionan por separado. Pero lo que realmente quiero es esto, déjame refrescar esto para que recoja el nuevo servidor. Lo que quiero es básicamente una consulta. Quiero una consulta en la que obtenga find cities, obtenga la ciudad de Ámsterdam y luego encuentre todas las diferentes cervecerías en Ámsterdam. Y lo hago en una sola consulta, un solo gráfico, como se llama. Entonces, ¿cómo lo hicimos? En realidad es bastante simple. Necesitaba agregar para extender el tipo, el tipo de ciudad y agregar al tipo de ciudad el campo de cervecerías. Así que solo, tenemos el esquema de ciudad, déjame mostrarte eso. ¿Dónde está el esquema de ciudad? Aquí, tengo el esquema de ciudad, el esquema no tiene cervecerías. Entonces, lo que necesito, básicamente, es tomar el esquema de ciudad y extenderlo desde otra fuente y agregar este campo de cervecerías. Pero luego también quiero crear los resolvedores para este campo. Y el resolvedor para este campo es básicamente lo que hace, toma, usa como la consulta raíz, como la raíz, la información raíz que obtuve del resolvedor principal, te lo mostraré en un segundo, como, porque esto se ejecutará bajo la ciudad. Entonces se ejecutará primero, el resolvedor de la ciudad obtendrá la información y luego se ejecutará este resolvedor, este resolvedor. Y si esto es básico de nuevo, está bien, solo quería repasarlo. Y luego tomará el valor de aquí, extraerá el nombre de él y lo enviará a la otra fuente de datos para encontrar cervecerías. Así que básicamente, estoy haciendo una extensión aquí. La razón por la que lo muestro ahora aquí es porque más tarde lo haremos con Mesh. Y nuevamente, utilizando las herramientas de GraphQL merge, solo tomo esas dos extensiones y las agrego aquí a la función resolvedora de merge. Si miras la diferencia, eso es todo lo que he hecho. Agregué esto y agregué esto y esto, y eso significa que ahora, si miro la documentación, por ejemplo, y estoy buscando, digamos, el tipo de ciudad, sí, el tipo de ciudad. Verás que tiene cervecerías. Y para las cervecerías, puedo ir aquí y obtener todas las cervecerías. Así que eso está bien. Si no creas este tipo de cosa, nuevamente, cambiemos a otra ciudad como Atenas y veamos si lo obtendrá. Genial. Eso está bien para mí. Actualmente estoy en Atenas, por cierto, así que ahora ya sé dónde están las cervecerías, aunque no puedo salir de casa. Así que. Así que esto será una forma automática de hacerlo en lugar de hacerlo manualmente, porque simplemente lo estás sobrescribiendo en lugar de ir al origen de los datos, ¿verdad? Así es, esta es la forma de hacerlo en GraphQL, no, pero la forma manual de hacerlo, ¿verdad? Necesitaba escribir ese código, ¿verdad? Sí. Así que necesitaba crear eso, le dije a GraphQL, mira, aquí hay un nuevo campo, y, ya sabes, aquí está cómo obtener los datos. Y porque es un campo bajo la ciudad, primero se ejecutará el resolvedor de la ciudad, como este resolvedor de findCities, como la raíz, básicamente la raíz, este, la consulta raíz. Entonces, primero se ejecutará la consulta raíz, obtendrá el resultado, el resultado vendrá de aquí. Y luego, porque es un campo bajo aquí, primero se ejecutará eso, tomará eso como un valor principal. Eso es lo que obtendré aquí en la raíz. Y luego tomo el valor principal. Lo que obtuve, selecciono el nombre de él y lo paso como parámetro a esta función. Y nuevamente, esta función puede provenir de algo completamente diferente, pero en nuestro caso, en realidad es la otra fuente de datos. Y ahora obtenemos la conexión. Obtenemos esta conexión entre una ciudad y una cervecería que creamos. Esas conexiones son lógica de negocio, ¿verdad? Esas conexiones, conoces esas conexiones porque creas el producto. Como si creo, no sé, digamos una aplicación diferente que no tiene nada que ver con alcohol, entonces no crearía esta conexión, ¿verdad? Sería extraño. Así que esto es como, llamémoslo lógica de negocio, pero tú creas el gráfico de tu propio producto. Espero que eso responda. Sí, lo siento. Sí, lo hace. Responde. Y esto es posible porque en lugar de, no irías al origen y editar el origen porque esto asume que no tienes acceso al origen, ¿correcto? Quiero decir, la señal, el origen es sí. Oh, entiendo. El origen es esto. Es como, en primer lugar, en este caso, es una API pública a la que no tengo acceso, pero también puede ser un microservicio. Como esto es algo que es responsable de las ciudades. Y queremos, no queremos que el equipo responsable de las ciudades sepa todo sobre las cervecerías, ¿verdad? Esa es la idea de los microservicios.

Eso es otra cosa, por cierto, que la gente confunde. Como si hicieras arquitectura en una gran empresa, es donde pertenece realmente el campo de cervecerías debajo de la ciudad. Muchos errores que la gente comete arquitectónicamente es que piensan que las cervecerías están bajo la ciudad, por lo que el equipo de la ciudad es responsable de ello. Pero ese no es el caso. En realidad, alguien más debería ser responsable de esto. Y tal vez ese alguien más, como, y es una pregunta, por cierto, tenemos muchas discusiones al respecto con muchas grandes empresas. ¿Este asunto pertenece al equipo de la ciudad, o este asunto pertenece al equipo de las cervecerías? O tal vez no pertenece a ninguno de ellos, en realidad pertenece al equipo de producto que construye la aplicación porque conocen la conexión. Como, tal vez a este equipo no le importan las ciudades, y a este equipo no le importan las cervecerías, y está bien de esa manera, porque pueden centrarse en su servicio. Y luego esta conexión puede venir de otro lugar. Así que esa es una pregunta más filosófica de quién es responsable de las conexiones, sobre la cual tengo muchas opiniones. Sí. Y luego, GODB sería como la base de datos de la ciudad o los datos de la ciudad. Y luego OpenBrewery sería como la fuente de cervecerías. Y luego el índice en este caso los une a ambos y te proporciona un nuevo punto final, por decirlo así, o una nueva consulta o una nueva mutación. Exactamente. Pero también podría crear aquí. Oh, lo siento, continúa. Entonces, básicamente este proyecto, o lo que estamos tratando de hacer ahora, es simplemente fusionar estos microservicios en uno y exponerlo nuevamente. Sí, exactamente. Y exponer la API que es mejor para el producto, para el consumidor. Sí, eso tiene mucho sentido. Es bastante genial. Y luego ves que actualmente lo estamos haciendo manualmente. Y ahora vamos a verificar la solución de cómo hacerlo con Mesh, ¿es correcto? Exactamente, exactamente. Sí, sí, es una buena manera de decirlo. Y es como, una vez más, por cierto, esta conexión, no, lo escribí aquí solo porque es simple, pero todo este código puede estar en otro archivo, nuevamente, como en otro equipo, tal vez el equipo de conexión o el equipo de la aplicación. Y luego, nuevamente, solo importa este código desde el equipo de la aplicación y colócalo aquí mismo en el tipo de fusión. Entonces, podrías poner eso, eso es solo para el punto de que no tienes que usar, no sé, Apollo Federation o schema stitching para separar entre diferentes equipos y la pasarela entre diferentes equipos, solo puedes importarlo y usar la fusión de GraphQL o si quieres algo un poco más sofisticado, usa los módulos de GraphQL que puse el enlace antes. Así que espero, por cierto, ¿todos tienen esto funcionando? ¿Como este paso actual? Podrías escribirlo manualmente, por cierto, solo estoy revisándolo, pero solo para ahorrarnos tiempo porque a ti no te importa que yo escriba, pero podrías escribirlo si quieres y puedes volver a este taller en cualquier momento. En el futuro, también agregaré más funciones, pero eso es básicamente todo lo que he hecho. Espero que todos tengan esto funcionando ahora y nuevamente tengan esto funcionando, ¿verdad? Lo hicimos, el primer paso fue simplemente crear un servidor GraphQL donde tomamos las fuentes de microservicios existentes que usamos o las fuentes que usamos, y simplemente elegimos los campos correctos que queremos, lo cual ya es genial. Pero luego también agregamos esta conexión. Entonces no solo podemos elegir los campos que queremos, también podemos crear en una solicitud. Podemos crear una consulta que haga esas conexiones. Y todo lo que te mostré hasta ahora es básicamente el tutorial más básico de GraphQL, como nada súper sofisticado, nada nuevo, pero aún es importante saberlo. Así que eso es genial. Pero ahora lo que vamos a hacer es llevarlo a, en realidad vamos a comenzar a usar Mesh, el GraphQL Mesh, que es lo que quería hablar. Así que déjame hacer eso. Detendré el servidor y lo revisaré, pero haré todos esos comandos contigo, y puedes hacer esto conmigo o revisar esta cosa. Voy a hacer yarn. ¿Por qué voy a hacer yarn? Porque básicamente, estamos instalando nuevas bibliotecas. ¿Qué nuevas bibliotecas? Veamos el package JSON. Entonces estamos instalando GraphQL Mesh. Eso significa que si no fuera perezoso, haría, como, déjame agregar esto. Haría, npm install, o sí, lo siento. npm install, o yarn add, graphql-mesh-cli. El CLI es como la biblioteca básica o la biblioteca principal que vamos a usar. GraphQL Mesh Config es la que, como, podemos enviar la configuración a. Runtime es la biblioteca que, en realidad, podemos ejecutar GraphQL Mesh, como, como un servidor. Como un servidor. Ya lo instalé aquí, pero la verdad es que podríamos hacerlo en el siguiente paso. Y luego instalamos, tenemos los controladores. Entonces estamos instalando GraphQL Mesh OpenAPI porque tenemos una fuente que tiene un esquema OpenAPI, que mostraré ahora, y otra fuente que es JSON Schema. Es una fuente que no tiene un esquema y queremos alimentarla con información y generar el esquema a partir de esa información. Así que veamos, así que ese es el primer paso que hemos hecho. Veamos si, probablemente tomará un poco de tiempo para que esto se instale. Eso está bien. Ahora, terminamos con Mesh, eso está bien. Pero, ¿qué queremos hacer en realidad? Queremos que tome las fuentes de datos que teníamos antes. Veámoslo aquí. Ves, eliminamos por completo esas fuentes de datos. Y queremos que ahora esas fuentes se creen para mí usando GraphQL Mesh. Entonces, lo primero en Mesh son las fuentes. Puedo definir cuántas fuentes quiero. Puedo nombrarlas en este caso, solo las estoy nombrando godb, pero puede ser, ya sabes, lo que quiera. Y luego, para cada fuente, básicamente necesito crear el controlador. Los controladores, si quieres obtener la lista de los controladores, vamos aquí, roughglmash.com. Y aquí en la documentación, puedes tener, oh, por cierto, primero aquí, también tienes un ejemplo en línea. Tomará un poco de tiempo cargar porque mi computadora me está gritando, pero aquí están todos los controladores que puedes usar. Entonces, en este caso, queremos usar OpenAPI y Swagger, así que simplemente haremos yarn add roughglmash. Y luego en el controlador, diremos OpenAPI. Y aquí tienes todas las opciones diferentes que puedes enviarle. Si quieres usar gRPC. Nuevamente, instalarás roughglmash.grpc, controlador gRPC, y luego obtendrás todas las configuraciones diferentes que puedes enviarle aquí. Lo mismo para SOAP y otros también. Sí, aquí está la lista de todo. En nuestro caso, queremos OpenAPI.

Entonces, en OpenAPI, las opciones que obtenemos, veamos nuevamente aquí. Tenemos fuente, formato de fuente, encabezados de operación, algo similar a las preguntas que se hicieron aquí. Para nosotros, lo único que nos importa actualmente es la fuente y la URL base. ¿Qué es la URL base? Básicamente, es lo mismo que configuramos aquí en la fuente de datos, ¿verdad? Solo es a dónde enviar las llamadas. Pero luego tenemos otra cosa. Esta es la fuente. ¿Qué es la fuente? La fuente es, en este caso, tenemos un esquema swagger y en este caso, es todo, incluso podemos llamar a una URL y obtenerlo. Así que simplemente colocamos la URL. Ahora, por cierto, no solo acepta URL. También puede aceptar un archivo local o lo que sea, ya sabes, lo tienes también, pero aquí tenemos toda esa información. Así que ahora podemos tomar todo esto y convertirlo en GraphQL. Así que eso es todo simplemente haciendo esto. Básicamente, déjame, el yarn star.

Entonces, ¿un handler es básicamente un protocolo? Sí, exactamente, exactamente. Entonces, porque puedo tener múltiples controladores de OpenAPI, puedo tener múltiples controladores de JSON schema, ¿verdad? Entonces, un handler es como, puedo hacer algo así, digamos otro aquí, y este es otro OpenAPI, pero eso llamará, ya sabes, no sé, HTTP.otra cosa.com, ¿sí? Y está bien. Y otra URL, como, ya sabes, otra cosa, cosa.com/swagger, ¿sí? Y ahora, y lo llamaré como, otra cosa source, lo que sea, ¿sí? Así, solo como ejemplo, ¿sí? Así que puedo tener tantas fuentes como quiera y a cada fuente solo necesito darle qué tipo de fuente es y qué controlador necesita.

Tengo una pregunta. Entonces, este archivo de configuración de Mesh parece estático. ¿Cómo puedo hacer que esta configuración sea específica del entorno? Así puedo ejecutar el mismo código en entornos de producción o integración, pero, por ejemplo, ¿cómo? Buena pregunta. Sí, buena pregunta. Tenemos soporte para variables de entorno. Creo que lo agregamos, cómo, lo tenemos como un ejemplo en algún lugar, tal vez en recetas. No lo recuerdo. Básicamente, sí, es posible. Puedes, en primer lugar, por cierto, todo también se puede ejecutar programáticamente. No lo mencioné, pero puedes cargar todo aquí que estoy haciendo estáticamente. También puedo hacerlo programáticamente. Puedo cargar esto programáticamente y ahora puedo cargar esto desde un archivo de código y no desde un archivo YAML, pero incluso en el archivo YAML tienes soporte para variables de entorno, por ejemplo, o encabezados u otras cosas. Como, creo que si simplemente buscas GraphQL mesh y variable de entorno, seguro que encontrarás algo como. Hmm, no lo sé. No quiero hacer eso. Deberíamos hacer que esta información sea más obvia, pero también en los ejemplos que tenemos. Sí, no es un problema. Es un caso de uso muy básico que muchas personas preguntan. No sé por qué no me muestra una fuente valiosa en la búsqueda de Google, pero se supone que debería. Voy a tomar nota de eso. Será mucho más fácil de ver y encontrar. Tal vez haya algo más aquí, no lo sé. Sí, puedo poner código raíz. Sí, no lo sé. Encontraré un ejemplo más adelante, pero es, debería ser fácil de encontrar. Nos hacen esta pregunta con frecuencia. De acuerdo. Pero solo quería mostrarte el total. Como, digamos, solo definir esto y ya está. Y de nuevo, eliminé la fuente de datos. Ahora, en los resolvers, veamos qué sucede. Veamos esto. Permíteme encontrar este código. Así que lo que voy a hacer ahora es encontrar y analizar la configuración de Mesh. Como aquí, no le estoy enviando nada, por lo que, ya sabes, lo predeterminado es como dot mesh o C dot YAML. Así que solo obtiene esa configuración de Mesh, obtienes la configuración de Mesh y luego obtienes el Mesh. Básicamente, le envío la configuración y me devolverá un SDK. Me lo devolverá así y luego puedo obtener el SDK. Así que este es el SDK. Ahora, ¿qué es ese SDK? Básicamente, en esta etapa, solo es una fuente de datos. ¿Por qué es mejor? Permíteme mostrarte. ¿Ves esto? Entonces, lo que ves aquí, esto es bastante genial, ¿verdad? Estoy enviando una solicitud REST, pero obtengo autocompletado. Obtengo autocompletado de todas las funciones posibles que esta API REST podría darme dentro de mi IDE si escribo algo extraño aquí, fallará la compilación. Y más que eso, si ahora, como enviaré algo aquí, va a, depende del archivo Swagger, pero incluso va a escribir mis argumentos. Entonces, ¿cómo sabe la API, o cómo sabe esta biblioteca cuáles son las consultas disponibles para que pueda fallar en el SDK? Ah, sí, esa es una buena pregunta. Entonces, como toma cada una de esas, ¿dónde está, permíteme encontrar, por ejemplo, para el protocolo HTTP, escuché que se supone, si sigues el protocolo HTTP, se supone que debes exponer esto, como todas las consultas posibles que puedes tener y cosas así, pero ¿qué pasa si no está implementado correctamente? Lo cual tiende a ser el caso. Sí, aquí no me baso en el hecho de que implementaron mis consultas. Los archivos Swagger básicamente describen puntos finales. Sé qué puntos finales, vamos a encontrar este punto final al que estoy llamando, ¿sí? Vamos al resolver del GODP, encuentra la configuración usando get. Ves, tengo esta operación, encuentro ciudades usando get. Esto es REST, sí, y esto es como, dice cuál es la URL para eso, dice cuáles son los parámetros. Y también me dice cuál es la respuesta, ¿sí? Entonces, básicamente puedo tomar eso y convertirlo en un SDK. Entonces, básicamente cada operación de aquí, no cuento con nada, solo cuento con el Swagger. Solo veo aquí, obtengo todas las operaciones que obtengo y obtengo, sí, y obtengo como una consulta, pero esto es, nuevamente, algo que puedes configurar. Obtengo esto y también obtengo el resultado. Como ves, el resultado también tiene un tipo. Ves aquí, el resultado también está tipado. Así que tengo esto y puedo obtener data y puedo obtener entradas y lo que sea, ¿sí? Así que esto está completamente tipado. Pero, ¿esto significa que depende del Swagger? Sí, entonces, bueno, buena pregunta. Esto es específicamente la implementación de Swagger. Entonces, lo que quiero hacer aquí es confiar en el Swagger. Creo que el Swagger es bueno, pero en primer lugar, como dices, tal vez el Swagger no esté completo o no sea preciso o algo así. Entonces puedo personalizarlo. No me baso en el hecho de que implementaron mis consultas. Los archivos Swagger básicamente describen puntos finales. Sé qué puntos finales, voy a tomar esto y convertirlo en esto. Y hacer lo que quiera allí. Si no confío en esto y también agregaré que cuando llegue a la cervecería abierta, verás que ni siquiera tengo un Swagger, pero llegaremos a eso en un segundo. Sí, lo siento, continúa con tu pregunta.

No, lo siento. Solo iba a decir que hasta ahora estaba tratando de ver cómo esto hacía mágicamente todo, pero ahora entiendo que básicamente es más una automatización para el trabajo manual. Entonces básicamente, estoy publicando esto como, ¿qué pasa si el swagger está equivocado? Pero el hecho es que si el swagger está equivocado, tampoco puedes hacerlo manualmente. Y ahí es donde entra en juego esto. Si no lo conoces, sí. Lo entiendo. Entonces lo que estás diciendo es que, si el swagger está equivocado, pero no sé que está equivocado. No, no, como usarías mesh si quisieras automatizar este proceso, ¿verdad? Pero también es como, está limitado a donde manualmente también podrías hacerlo. Ah, sí, te refieres a que si pudieras adivinar las cosas, no sé, ¿cómo lo harías? Estoy tratando de entender cómo lo harías de otra manera. Sí, exactamente, eso es lo que quiero decir. Pensé que automáticamente adivinaría estas cosas que no podrías hacer manualmente, me gustaría hacerlo de alguna manera, no sé, revisando todas las consultas o algo así. Pero ahora veo que no es así, solo es para hacer el proceso manual. Mm, entiendo. No entendía exactamente qué era mesh, y ahora sí, eso es lo que estoy tratando de decir. Ok, ok, así que esta es una parte de ello, hay otra parte, que es otro caso de uso más avanzado que también hacemos en algunos clientes, que es, intentemos adivinar esas cosas. Pero eso está más relacionado con la parte del esquema JSON, llegaré a eso, ¿sí? Llegaremos allí. También te mostraré lo que creo que quieres decir, pero esto es un poco más avanzado, como quiero hacerlo paso a paso. Entonces sí, aquí lo que, nuevamente, lo primero que estoy haciendo es confiar en esto. Creo... Creo en G-O-D-B, que su swagger es correcto. Pero nuevamente, en lugar de tener lo que tenía antes, que es esta fuente de datos REST, no tenía ningún tipo. Y si cometiera errores aquí, no lo sabría. Nuevamente, obtengo esto de cómo completar y todo lo que hemos visto aquí. Y también aquí... ¿Dónde está? Aquí, por ejemplo, en la configuración de la cervecería, también obtengo la entrada. Entonces, si escribo esto, obtengo un error. Nuevamente, esta es una API REST. Esto no es una API GraphQL. Y aún así obtengo los errores en el editor. Entonces eso es en mi opinión, como el primer... Este es como, digamos que ya estás usando GraphQL. Este es el lugar más fácil para comenzar a usar mesh. Puedes comenzar a obtener los beneficios de GraphQL en lugar de tus antiguas fuentes de datos. Como, no necesitas reemplazar todo tu código y todo y veamos todos... ¿Cuáles son los cambios que he hecho aquí? Entonces esta es una fuente. Solo le digo dónde hacer la consulta desde y la fuente del swagger, eso básicamente desde aquí generaré el SDK, pero luego tengo otra fuente. OpenBrewery. Disculpa. Sí, sí, sí. Si quiero pasar la autenticación ¿dónde necesito poner ese código? Aquí, déjame mostrarte. Por cierto, aquí tienes una lista de ellos. Por cierto, déjame, intentaré encontrar también un ejemplo de lo que dijiste, pero aquí básicamente tienes encabezados de operación, encabezados de esquema, como por ejemplo, los encabezados de esquema son como... Si quieres obtener eso, digamos que este esquema es público como el esquema Swagger real es público, pero digamos que incluso el esquema en sí no era público y aún así quieres incluso autenticarte solo para obtener el esquema, entonces lo pasas con los encabezados de esquema y los encabezados de operación es donde envías el actual, cuando llamas algo y pasas por ello, lo que quieras, JWT o lo que quieras enviar a través de él. Sí, pero si lo estoy haciendo manualmente, estoy en este paso donde solo uso el SDK, cuando construye el SDK, pasará automáticamente los encabezados y solo puedo llamar a esa función donde estás ahora en el código. Si quieres. Sí, sí, exactamente, sí, sí, sí. Como puedes. Ah, entonces lo hará automáticamente. No tengo que hacer algo, ponerlo aquí en el resolutor. No tengo que consultar el contexto o tomar algo del contexto y pasarlo a través del. No, es una buena pregunta. Entonces tienes dos opciones. Una es que podrías tomarlo del contexto y luego pasarlo como un parámetro o algo así. Pero también lo que podrías hacer es hacer referencia al contexto aquí. Como lo que podrías hacer es algo así como los encabezados de operación y luego puedes hacer referencia a algo así, como no estoy seguro de hacerlo luego obtener exactamente lo correcto. Pero puedo buscar más tarde en el contexto punto lo que sea. Sí, y luego puedes pasarlo, sí. Y creo que tenemos varios ejemplos así. No recuerdo cuál es cuál. Déjame ver si hay algo obvio que recuerdo. Ves que hay muchas cosas aquí. Creo que la API de Stripe tiene algo así. No estoy seguro, déjame ver el código de mesh. Sí, ves aquí, encabezados de operación. Y luego obtienes el encabezado de autorización y luego obtienes el padre del token de Stripe y luego el token que obtienes de una variable de entorno, o algo así. Entonces tienes diferentes opciones para hacer eso. Hay más opciones. Sí, gracias. Sí, entonces, ok. Así fue esta fuente, esta fuente, pero luego tenemos otra fuente, la fuente OpenBrewery. Ahora la fuente OpenBrewery es un poco menos agradable que la fuente GeoDB porque no tenemos un esquema. Como mucho, obtenemos solo el sitio web de documentación. Y tal vez eso ni siquiera es algo que obtengamos. Entonces ves, no tienen un esquema. En este caso, lo que he hecho es que tienen ejemplos de salida y ejemplos de entrada. Ves, tienen CD por nombre. Entonces lo que he hecho, puedes ver nuevamente en la, volvamos a la diferencia. Demasiadas pestañas. ¿Dónde lo encuentro? Sí. Solo me detendré aquí. Entonces lo que he hecho aquí, creé una muestra de entrada de cervecerías y solo copié y pegué esto del sitio web. Sí, y luego esto es como una muestra de respuesta. Como ejemplo, ejemplo de entrada, salida. Y luego le dije a mesh, oye, esto es este controlador, la muestra de cervecería abierta. Este es un controlador de esquema JSON. Es un controlador diferente al de la API abierta. Esta es la URL base. Aquí es donde lo llamas. Pero aquí están las operaciones. Como tienes una consulta, en la consulta tienes cervecerías llenas y este es el camino y este es el método.

Y para el esquema, quiero que generes el esquema JSON. Aquí tienes un ejemplo de solicitud y aquí tienes un ejemplo de respuesta. Y nuevamente, esas cosas las podría obtener de cualquier lugar. Entonces, esto es, y aquí puedes llegar a ser muy avanzado y muy astuto. Esto también está relacionado un poco con lo que preguntaste antes. Olvidé tu nombre, por cierto. Lo siento, ¿puedes repetir tu nombre que preguntaste acerca de cómo encontrar automáticamente esas conexiones y cosas así? Olvidé tu nombre. ¿Juan? Juan, de acuerdo. Juan preguntó si podemos encontrar automáticamente esas cosas. Entonces, aquí, en primer lugar, obtengo un ejemplo como logs y puedo conectar y dirigir esto a mi DataDog o cualquier cosa que use para consultar, para almacenar algunas respuestas o algo así. Aquí, simplemente lo copié del sitio web de ejemplo, pero puedo obtener más, y luego hay toneladas de herramientas que nos ayudarían básicamente a tomar esto y generar el esquema a partir de él. Y así, y aquí puedes llegar a ser muy, hay muchas, muchas herramientas interesantes, pero como adivinar cosas y todo, y podrías ajustar esas cosas. Pero aquí estoy usando deliberadamente el ejemplo más simple. Tengo esos ejemplos, no tengo un esquema y aún así, GraphQL Mesh generará ese mismo SDK del que estaba hablando. Entonces, aún así, si tomo el SDK y hago aquí y tengo brewery, obtendré esta cosa y estará completamente tipada. Ves, tengo las variables y todo y también el tipo de retorno. Entonces, sabes, si vuelvo aquí, esta cosa está tipada. Sé exactamente lo que voy a obtener aquí. Sí. Así que eso es extremadamente valioso. Por eso, solo al hacer esto simple, estoy avanzando muy lentamente en todo lo que he hecho aquí, pero como para los cambios y todo. Pero básicamente no cambié mucho, ¿verdad? Simplemente instalé Mesh. Le di a Mesh esta entrada y la ejecuté aquí para generar un SDK. Y eso es todo. Ahora tengo un SDK completamente generado con todos los tipos y cosas que me llevarían siglos crear y también mantener actualizado y todo. Y podría eliminar la fuente de datos y simplemente reemplazarla con esto, ya sabes, el SDK que importo de la cosa generada. Entonces, si tienes servidores GraphQL existentes hoy, este es el primer paso que puedes hacer y puedes hacerlo en cuestión de minutos. Y ahora obtienes no solo tipos en tu código GraphQL, sino también tipos dentro del resolutor que llama a tus antiguos servicios REST. Así que eso es algo muy poderoso.

Por cierto, déjame ver si hay personas que quieren unirse. Sigo perdiendo a las personas que quieren unirse. De acuerdo, sí. Sí. Incluso fuera del contexto de GraphQL, esta forma de poder estudiar, no estoy seguro del verbo, toda la biblioteca del cliente, todos los servidores, es realmente interesante. Sí, exactamente, exactamente. Entonces, esto es muy interesante porque ese es el punto que puedes usar. Esa es la única cosa que es muy difícil de explicar a las personas. Esta biblioteca, simplemente elimina el nombre GraphQL y sigue siendo muy valiosa, ¿verdad? Como todas esas cosas, esto está relacionado, esto también está relacionado con el hecho de que GraphQL es solo una evolución, en mi opinión, de otras APIs. Entonces, podrías usar las mismas técnicas y herramientas y todo en el mundo de GraphQL, simplemente no lo llames GraphQL, ¿sabes? Sí, pero este cliente de biblioteca, ¿está disponible fuera de la biblioteca de mesh? Sí, quiero decir, esta es la biblioteca de mesh. Simplemente, no necesitas, sucede que se llama GraphQL mesh, pero puedes, nuevamente, todo lo que he hecho aquí, obtienes el SDK seguro, ¿verdad? Entonces, este SDK, como sabes, solo llamé al SDK, sí, entonces esto es, lo pongo en el contexto, déjame usarlo aquí, más fácil, sí. Entonces, SDK, ves aquí? Entonces, tal vez ni siquiera use GraphQL. Tal vez esto sea solo un servidor Express regular, ¿verdad? Y obtengo todos esos beneficios. Entonces tienes mucha razón, como esto es algo que, incluso si no estás, estoy haciendo este taller aquí porque comencé desde GraphQL porque la mayoría de las personas vienen con el conocimiento de GraphQL. Pero eso es lo que quiero decir. Podría hacer la misma conferencia, eliminar Apollo Server de aquí por completo y simplemente hacer SDK, lo que sea, y podríamos estar en una conferencia de Express, ¿sabes? O en una conferencia de React Native o una conferencia de React donde hago este SDK pero simplemente lo ejecuto en el cliente. ¿Verdad? No en el servidor. Sí, eso es un punto muy bueno. De acuerdo, eso es todo lo que he hecho, ¿verdad? Tengo este SDK y simplemente sucede que lo uso en el servidor GraphQL que escribí. Así que eso es genial. Eso es GraphQL Mesh. Bastante genial, creo. Una biblioteca bastante genial. Y ya lo estamos usando. Así que eso es bueno. Ahora quiero pasar al siguiente paso. Permíteme saltar a eso. Y veamos cuál es el siguiente paso. De acuerdo, primero que nada, detengamos el servidor y luego hagamos un yarn de nuevo. No porque en realidad esté instalando algo nuevo, sino porque ahora estoy eliminando muchas cosas de NPM. Y vamos a ver qué eliminé justo ahora. Mientras se está ejecutando y eliminando algunas cosas, veamos el commit. En primer lugar, el commit dice cambiar a mesh serve en lugar del SDK y Apollo Server. Solíamos usar mesh como un SDK dentro de Apollo Server. Pero ahora lo que estamos diciendo básicamente es, vamos a eliminar. En realidad podemos tomar mesh y déjame mostrarte. Puedes ver cuánto código eliminamos aquí. Pero déjame ir aquí. Sí. Veamos el código por un segundo. Nuevamente, quiero cargar esto. catch. Yarn. Yarn start. De acuerdo. Veamos qué está sucediendo aquí. ¿Qué hace yarn start? Yarn start hace mesh serve. Ya no va a index.ts. Viste que index.ts, básicamente la cosa que, ya sabes, nuestro archivo principal del servidor donde déjame encontrarlo aquí. Esta cosa se ha ido, no más Apollo Server. ¿Con qué lo reemplacé? Vamos a mesh. Tenía las mismas fuentes aquí que antes. Vamos a omitir esta parte por un segundo. Vamos a olvidarnos de esta parte por un segundo. Simplemente lo eliminaré así. Solo dije serve port 4000. Aquí tienes una consulta de ejemplo para que la muestres. Y esto, no tienes que hacerlo. Sí, puedes eliminar esto. Esto es solo, quiero obtener esta consulta solo para ponerla en el playground gráfico, pero no es realmente necesario. Entonces, también ahora GraphQL Mesh es nuestra puerta de enlace de API. Hace todo por nosotros.

Así que eso es genial. Entonces, esto es todo, pero... Espera, déjame también... Un segundo. Sí, pero aún así, tenía algo de lógica en esto, ¿dónde está, tenía algo de lógica aquí, verdad? Creé esto, cosas adicionales que quiero y todavía necesito esas cosas adicionales porque solo con esas fuentes no es suficiente. Esas fuentes básicamente generan este SDK para mí, para que pueda llamar a este controlador como un GraphQL y este controlador como un GraphQL, pero no es suficiente, ¿verdad? No, quería hacer más que simplemente llamar a find cities y simplemente llamar a find breweries. Quería tener las cervecerías debajo de la ciudad. ¿Cómo lo hice? También podría ponerlo aquí. Podría tener profundidades de tipo adicionales. Puedo tomar todas esas fuentes diferentes, generar los esquemas de GraphQL a partir de ellas y luego agregar lo que quiera. Entonces ves, extendí el tipo en este caso porque fue generado. Ya no se llama city. Se llama resumen del lugar poblado porque realmente solo genera, como solo es un tipo generado a partir de las fuentes. Y simplemente agregué cervecerías debajo de esta cosa. Entonces, este es un esquema manual que puedo agregar a mi esquema generado. Y aún quiero un resolutor. Quiero algo que conecte esos dos. Entonces, en este caso, lo que estoy haciendo es llamar, moví la lógica que tenía antes si recuerdas del resolutor, simplemente lo moví a un archivo de código que uso aquí. Y nuevamente, todavía uso, ya sabes, esta cosa y aún está actualizada, ya sabes, como generada automáticamente, como todo el código aquí está completamente tipado. Como ves aquí, esto también está completamente tipado, este resolutor, porque conozco todas las entradas y salidas al igual que el generador de código GraphQL. Pero también conozco el contexto y todo lo que viene con él. Como, ya sabes, Open API, la API de la cervecería, todas esas cosas completamente tipadas. Y simplemente, mientras tengo todo esto completamente tipado, puedo crear la conexión. Y sé que es en tiempo de compilación, funciona porque está completamente tipado. Y en lugar de tener ahora como importado y todas esas cosas, mesh es mi servidor. Entonces, simplemente tomé resolutores adicionales y referencié el archivo. Eso es todo. Entonces ahora nuevamente, eliminé completamente el servidor de Apollo y simplemente lo actualicé. Y sí, oh, lo siento. Quiero volver. No, nunca. Así que quería mostrarte que la primera consulta no funcionó porque ahora esto está generado. Ya no se llama cities, se llama find cities usando get porque find cities usando get es en realidad un GraphQL. Ves aquí, generó todas las diferentes APIs como GraphQL. Entonces puedo simplemente comenzar a consultar esto como si fuera un GraphQL, ya sabes, puedo agregar aquí. Sé que en city, puedo agregar cualquier otra cosa que pueda tomar de, ya sabes, como país y cosas así. ¿Qué más queremos? Obtenemos ese ID, lo que sea. Y luego también puedo tener cervecerías. Y de las cervecerías, nuevamente, puedo consultar lo que quiera. Es como código posible, pero igual. Puedo enviar esto y obtengo todos los resultados. Así que obtuve aquí nuevamente, una puerta de enlace GraphQL que llama a las diferentes fuentes con una cantidad muy pequeña de código. Veamos todo el código que eliminamos. Entonces eliminé muchas bibliotecas, sí, pero eliminé los resolutores y los typedefs. Eliminé los índices, también los resolutores y typedefs de OpenBrewery. Como eliminé la mayor parte del código, pero aún funciona como antes. Entonces eso es muy, muy poderoso. Así que eso es genial, pero tal vez podamos hacerlo aún mejor. Así que pasemos al último paso, que se llama sin código. ¿Puedo hacer una pregunta mientras tanto? ¿Es posible tener algún modo de depuración para entender realmente qué consultas reales se están ejecutando detrás de escena por el mesh? Ah sí, sí, te refieres a básicamente cuáles son las, no son consultas, pero cuáles son las, solicitudes de red. Solicitudes, las solicitudes de red. Sí, sí, sí, sí. Tenemos, es solo un middleware, puedes ponerlo allí. Sí, creo, quiero decir, nuevamente, ya lo tenemos, pero no estoy seguro de si es muy visible. Entonces, si no está claro desde su sitio web, avíseme y mejoraremos eso. Ah, quiero mostrarte algo por cierto. Solo un segundo, pero sí, por supuesto, nuevamente, esta cosa actúa como una puerta de enlace. Entonces, todas las cosas que desearías de una puerta de enlace, por ejemplo, te daré otro ejemplo. ¿Qué pasa si quiero comenzar a actualizar esas cosas en tiempo de ejecución, como tengo un servicio y ahora se actualiza? ¿Cómo lo haces, ya sabes, cuando tienes una gran puerta de enlace que ahora funciona entre muchos, con muchas fuentes diferentes, esas fuentes pueden estar actualizadas y no queremos tener tiempo de inactividad. No queremos derribar la puerta de enlace, recompilarla y hacer esas cosas. Entonces todas esas cosas son posibles. La documentación actualmente a veces falta, pero es posible. Y en cuanto a la documentación, solo antes de pasar al último paso, quiero mostrarte algo. Si vas a GraphQL Mesh o, si vas a GraphQL Mesh o cualquiera de nuestros sitios web, ves esta cosa, es lo molesto que salta aquí. Esto parece una cosa de marketing molesta, como un bot molesto que te pedirá que compres algo de la guild o algo así, pero no, esto es solo un chat real que realmente llega a nosotros. Y respondemos aquí a muchas personas. Cada vez que damos una respuesta aquí, les pedimos a las personas, está bien, te conseguimos la respuesta, ahora dinos cómo mejorar la documentación para que ya no tengamos eso. Y esto es en todos nuestros sitios web. Como si voy a la guild, y ahora si vas aquí al sitio web y vas a código abierto, y tenemos módulos de GraphQL y CLI de GraphQL y configuración de GraphQL y herramientas de GraphQL, digamos si voy aquí, voy a la documentación, nuevamente, puedes hablar y hacer preguntas. Así que solo quería hacerte saber eso. Es muy fácil comunicarse con nosotros y hacer preguntas y recibimos muchas de ellas. Ah, por cierto, en otros lugares, como este, también tenemos nuestro propio Discord, donde puedes ver que mucha gente está hablando todo el tiempo y tenemos todas las diferentes bibliotecas de código abierto que puedes mantener. Simplemente puedes venir, hacer preguntas, tener debates. Sí, solo para que lo sepas. Y también puedes, como dije, ir a mi Github y preguntar directamente, pero sí. De acuerdo, espero haber respondido tu pregunta y si no, pregúntame de nuevo. Sí, tengo la respuesta. De acuerdo. Ahora veamos el código. Este es el último paso. No hay código. Básicamente hay un package.json y un archivo MesHRC. Eso es todo, ¿verdad? Lo que cambié aquí, déjame mostrarte esto. Ve a la sección sin código. Entonces, lo que necesitaba agregar básicamente era reemplazar el resolutor. Como si recuerdas, tenía un resolutor adicional y lo escribí en código, pero en lugar de escribirlo en código, lo escribí en un archivo de configuración, simplemente conecté el root al root, de lo que hablaré en un segundo, pero luego eliminé este mesh y es solo mesh serve. Eliminé todas esas dependencias. TypeScript y todas las cosas en tiempo de ejecución y la configuración de VS, todas esas cosas.

Básicamente, ahora solo tengo un archivo mesh RC y un paquete JSON. También tengo el archivo mesh RC como un ejemplo aquí. Todavía tengo esos ejemplos, como ejemplo JSON. Pero nuevamente, sabes, estos son solo ejemplos, por lo que mesh podría generar, pero eso es todo. Entonces eso significa que solo puedes tomar el archivo mesh RC y eso es todo. Este archivo package JSON siempre es el mismo.

Por cierto, de la comunidad, si escribes GraphQL mesh Docker, veamos. Entonces ves que la comunidad acaba de crear esto, por ejemplo, algo donde, creo que hay una imagen aquí. Simplemente tomas un contenedor Docker, como un contenedor de mesh, simplemente le envías el archivo mesh RC y listo. Tienes una puerta de enlace GraphQL para todas tus fuentes. Eso es todo. Solo el archivo mesh RC. Y nuevamente, ese archivo mesh RC, te lo mostré aquí como un ejemplo muy básico, pero podemos agregar aquí una cantidad infinita de controladores. Puedes personalizar, ya sabes, todo esto aquí y mucho más.

Entonces eso es como el taller básico. Básicamente, la idea aquí, nuevamente, si vas al taller, aquí ves que no hay muchos archivos aquí y todos esos archivos nuevamente pueden ser reemplazados solo por el archivo mesh RC y un contenedor Docker. Eso es todo. Y obtienes un tiempo de ejecución, como la puerta de enlace. Permíteme mostrarte que todo sigue funcionando. Usa yarn para eliminar toda la basura. Supongo que deberías tener alguna herramienta para validar que el archivo mesh RC sea realmente un archivo correcto porque básicamente... Sí, sí, sí. Entonces, primero, no sé si, tal vez no está instalado aquí, pero tenemos un esquema JSON que también describe el archivo RC. Entonces, te dará autocompletado y, ya sabes, obtendrás errores si esto no es handler sino handler. Creo que no lo instalé aquí, pero también lo tenemos para el archivo YAML de Cogent, y hacemos lo mismo. Sí. Entonces me pregunto qué quería mostrar. Quería mostrar que todavía funciona. Así que déjame presionar. Eliminemos algunas cosas para que veas que es diferente. Entonces, nuevamente, si piensas en dónde comenzamos, que es donde comenzamos, probablemente si supieras, digamos que comenzarías, digamos que comenzarías un taller de servidor GraphQL para GraphQL Galaxy, donde comenzamos es donde terminarías. Es donde terminarías que funciona, ¿verdad? Como este lugar, el código aquí en el primer commit, este es el final del taller de GraphQL. Pero tomamos todo lo que has hecho en un taller completo de GraphQL y básicamente lo convertimos en un solo archivo mesh RC. Y eso es el poder de mesh. Y el poder de mesh es que también lo hicimos gradualmente. Comenzaste simplemente usándolo como un SDK. Y como alguien dijo aquí, que es algo muy, muy inteligente de decir, creo que es como, no tiene nada que ver con GraphQL. Podrías comenzar a usarlo hoy en tus aplicaciones REST y en tu código de cliente sin siquiera pensar en GraphQL. Entonces es algo extremadamente poderoso. Sí, ahora quiero mencionar otra cosa que podría ser importante aquí. Así que hemos estado aquí, esas fuentes. También teníamos algunos resolutores adicionales y cosas así. Sí, y creamos esta conexión entre esos dos. Es como lo que mostré en las diapositivas, primero tomamos esos y los convertimos en GraphQL y luego los convertimos en un gráfico en una sola cosa. Convertirlo en un gráfico, tienes algunas opciones. Quiero mostrarte eso. Vamos a GraphQLMesh.com. ¿Cuánto tiempo tenemos? Sí, tenemos más tiempo, está bien. Entonces, si vamos aquí, puedes ver aquí todas las cosas básicas y todo. Instalación, uso básico, Match, Transforms, nuevamente, te mostré algunos. Esto es, sí, más tarde puedes ver las transformaciones, es muy interesante. Si quieres obtener más que casos de uso básicos y todo y hay muchas cosas aquí. Ampliación del esquema con múltiples APIs. Como dije, tengo múltiples APIs diferentes y quiero conectarlas. Entonces, como dije, hay, puedes usar resolutores adicionales y simplemente los adjuntamos y creamos esas cosas, pero también puedes usar el esquema. Entonces, la fusión de múltiples, hay muchas formas de fusionar múltiples servidores GraphQL en ejecución. La mayoría de las personas conocen o han oído hablar de Apollo Federation. Entonces, en primer lugar, con GraphQL Mesh, podrías elegir. Entonces podrías usar Apollo Federation como estrategia de fusión. Entonces puedo declarar la federación de fusión y luego puedo decir, si conoces Apollo Federation, has oído hablar de eso. Hay, puedes usar directivas para decir qué campo, qué fuente está conectada entre sí. Aquí puedes usar lo mismo. De hecho, usamos Apollo Federation para fusionar esas diferentes fuentes. Pero hay otro, hay un competidor de Apollo Federation que es schema stitching. Ahora la gente piensa que schema stitching está obsoleto, pero eso no es cierto. Quería mostrarte algo. Voy a compartir una publicación de blog que creo que deberías leer. ¿Qué es schema stitching? Schema stitching es... Espera, déjame... Mi auricular está muerto. Así que dime si... Espera. ¿Todavía puedes escucharme ahora? Sí, podemos. De acuerdo. Entonces, schema stitching y Apollo Federation es básicamente la idea. ¿Qué pasa si tenemos múltiples fuentes de GraphQL y queremos convertirlas en un solo gráfico, una sola API de GraphQL? ¿No era eso lo que estábamos haciendo? Incluso lo hicimos. Tomamos incluso algo que no es GraphQL, lo convertimos en GraphQL y luego la siguiente fase es fusionarlo. Sí, cierto. Tienes razón. Así que, sí. Entonces, fusionar esos, digamos, es una gran discusión en el mundo de GraphQL, como no voy a profundizar demasiado en eso, pero voy a poner esta publicación de blog para que puedas leer más al respecto. Es una publicación de blog importante si estás, porque mucha gente está hablando de Apollo Federation y piensan que es la única opción, o piensan que Apollo Federation, básicamente, que había schema stitching, y luego Apollo Federation es la próxima generación de schema stitching. Pero eso no es del todo cierto. Solía ser que Apollo mantenía schema stitching. Dejaron de mantenerlo. Nosotros lo tomamos y lo hicimos hoy, en mi opinión, mejor que Apollo Federation. Si te desplazas aquí y lees esto, puedes encontrar aquí una publicación de blog de Vox Media que básicamente dice, ¿debería usar Apollo Federation o schema stitching? Y cómo decidieron ellos.

Solo lo menciono para las personas aquí que son del mundo Grafton. No... Si ya estás en la comunidad y has oído hablar de la fusión de esquemas de Apollo Federation, solo quiero que sepas que la fusión de esquemas ha cambiado mucho, mucho, mucho, mucho. Y lo estoy mencionando aquí. Creo que es la fuente más importante que existe hoy en día para hacer esas cosas. Y en mi charla en la conferencia, hablo sobre por qué y por qué es importante.

Básicamente, esto es cómo ejecutar una puerta de enlace que fusiona y une múltiples servicios GraphQL en ejecución. Instancias separadas. Así que piensa en ello como un servicio GraphQL, pero no tienes control sobre ellos, ¿verdad? Que están fuera de tu control. ¿Cómo los fusionas en un único punto final y los ejecutas? ¿Y cómo los actualizas mientras se ejecutan, como la recarga de esquemas completa? ¿Cómo haces la fusión? Hay muchas formas diferentes de fusionarlos. Solo te mostraré dónde está GraphQL, mencionaré un poco y luego responderemos preguntas, pero veamos la fusión de esquemas, la fusión de tipos, básicamente, ¿cómo tomas múltiples servidores remotos y los fusionas? Puedes hacerlo con código o incluso, si da una explicación de cómo funciona en ejecución y sigue siendo rápido y eficiente. Veamos si tienen directivas aquí. ¿Y cómo declaras esas estrategias de fusión de forma declarativa con directivas? No voy a entrar mucho en eso, pero si tienes preguntas al respecto, me encantaría responder. Creo que eso es todo por hoy. Ahora, hay más cosas que queremos agregar para el taller en el futuro. Pero hoy puedes hacer cosas como mencionaste, ¿cómo pasas encabezados y autenticación, diferentes formas de fusión como esa, tal vez aquí usando directivas, cómo recargar en vivo los servicios, mostrar más controladores. Creo que esto es un buen comienzo para muchas cosas. Así que tal vez ahora podríamos pasar a las preguntas y luego puedo mostrarte más, según las preguntas. Permíteme detener el uso compartido de pantalla. Sí.`

Tengo una pregunta un poco fuera de tema que me preguntaba por un segundo. Vimos la herramienta Klee que agregaste a los paquetes. Me preguntaba, por ejemplo, ¿se pueden generar los esquemas o generar el tipo, lo siento, se ejecutaría un comando en la terminal, ¿verdad? Para generar... Ah, sí, oh, tal vez no lo mostré. Entonces, en el archivo package JSON, por cierto, de cada confirmación, puedes encontrar los comandos que necesitas ejecutar. Entonces, si quieres ejecutarlo como un SDK, entonces tienes un comando como generar SDK o algo así, espera, te lo diré exactamente. Mesh generate SDK, sí, para que puedas enviar una bandera para ello, como dónde generar el código generado o algo así. Así que ese es un comando para Mesh. Y luego hay otro comando, y nuevamente, en un Mesh separado, el paquete runtime que puedes ejecutar mesh serve y eso ejecutará Mesh como su propio servidor. Y con respecto a esto, esto es como nuestra curiosidad, ¿qué está ejecutando Klee por debajo? ¿Qué está usando para analizar los comandos o para analizar el código, como para analizar el código y generar el código? ¿Te refieres a la línea de comandos? ¿Qué quieres decir? ¿Como una herramienta que hace qué? No estoy seguro de lo que entiendo. Creo que es un GraphQL. Bueno, creo que básicamente es el servidor GraphQL que se está ejecutando allí. Ah, ¿qué servidor GraphQL se está ejecutando si lo estamos ejecutando como un servidor? Sí. Ah, una buena pregunta. Solía ser, porque en realidad ha cambiado esta semana. Solía ser Express GraphQL y lo cambiamos a GraphQL Helix, la biblioteca a la que hice referencia, la puse en el chat, porque creemos que es mucho mejor. Sí. En ese sentido, en términos de rendimiento, elijo Express GraphQL solo porque, ya sabes, según una pequeña prueba de referencia que encontré, bueno, en realidad varias, el servidor Apollo es un poco lento cuando el rendimiento es alto. Entonces supongo que el servidor en términos de rendimiento está por delante del servidor Apollo, pero ¿está por delante del servidor Express GraphQL también? Entonces, GraphQL Helix, es una buena pregunta. Entonces, GraphQL Helix, en primer lugar, sí, tienes razón. El servidor Apollo, y espero que más personas lo sepan, es básicamente, es lento y está desactualizado. Es porque no está mantenido, para ser honesto. Como que no le dedican tiempo. Solía trabajar en Apollo, por cierto, y durante muchos años, no están actualizando esa biblioteca, por lo que las dependencias están actualizadas. Y como dijiste, el rendimiento no es tan bueno y han fusionado muchas cosas diferentes. Así que está bien si tienes un marco que lo junta todo, siempre y cuando sigas manteniéndolo. Si te quedas atrapado manteniéndolo, todas las diferentes dependencias se están quedando obsoletas. Así es el servidor Apollo. Ahora, Express GraphQL estoy de acuerdo en que es mejor, pero Express GraphQL tampoco está muy mantenido. Lo bueno de GraphQL Helix es que separa las partes del esquema del servidor web. Entonces puedes usar GraphQL Helix con Express, puedes usar GraphQL Helix con Festify, puedes usar GraphQL Helix con Coa o lo que quieras. Y en mi opinión, y no solo es muy liviano y muy rápido y no pone, como que es extremadamente rápido. Como que puedes, todas las pruebas de referencia que viste probablemente de Ben Awad y cosas así, como que GraphQL Helix se agregará allí y ganará, porque puedes ponerlo con digamos Festify o ponerlo con GraphQL JIT o todas las cosas más rápidas. Y también lo mejor de todo es que puedes usar cualquier versión de GraphQLJS que desees, incluidas las cosas experimentales. Así que eso significa que ahora puedes usar defer, por ejemplo, y todas las cosas nuevas. Realmente lo recomiendo mucho y acabamos de cambiar a esta biblioteca internamente en Mesh y en nuestras propias aplicaciones y con clientes lo recomiendo mucho. Definitivamente lo probaré. Todavía estábamos en las primeras etapas, así que creo que ahora es el momento. Y sigue a Daniel, el chico que lo escribió. Es como a tiempo parcial en Guild y a tiempo parcial en otras cosas y es muy inteligente. Así que sí, puedes seguirlo y hay muchas cosas interesantes sucediendo ahora. Envié un enlace a la publicación del blog para que puedas seguir nuestro blog, estamos actualizando constantemente las cosas allí y simplemente leerlo. Hay muchas cosas que a veces la gente se pierde. Sí. Gracias. Tengo una pregunta. Entonces, digamos que quiero ejecutar Mesh en producción. Pero también quiero tener registro o establecer métricas en Grafana o Prometheus o habilitar el trazado. Sí. ¿Cómo puedo hacerlo? Sí, simplemente puedes definir cualquier middleware que desees y también tienes hooks. Puedes engancharte en las cosas del ciclo de vida. Lo que estamos tratando de hacer ahora, no es que debas preocuparte por ello. Pero para nosotros, nos importa que hacer trazado abierto hoy en día con GraphQL es extraño. Necesitas como anular la función execute y todo tipo de cosas extrañas. Ahora estamos trabajando en una nueva cosa en la especificación donde obtienes hooks de ciclo de vida directamente en la ejecución de GraphQL. Entonces será extremadamente fácil agregar cualquier solución de trazado que desees. Nuevamente, es posible, pero internamente la solución en nuestra opinión es un poco fea. Pero estamos trabajando en algo aún mejor. Pero cuando digo fea, esto es para cualquier servidor GraphQL, no está relacionado específicamente con Mesh. Sí, es una buena pregunta.

Tengo una pregunta sobre las suscripciones. ¿También maneja las suscripciones? Me interesa más comunicarme directamente con Kafka o Nats o Redis o algo así, no con otro GraphQL.

Excelente pregunta. Déjame enviarte también una buena respuesta para eso. Solo escúchala de nuevo. Encontré la publicación del blog al respecto, pero dice que vendrá con otra publicación de blog. No logré encontrar ningún ejemplo. ¿Cuál? ¿Te refieres a esto? Permíteme citar la publicación del blog y dime si esta es la publicación a la que te refieres. Sí, esta es la que encontré en algún lugar. ¿Y quieres un ejemplo con Kafka? Sí, Kafka, no sé si hay algo más. De acuerdo, podemos editar, es la misma idea. Como que tenemos, sí, supongo que no lo hicimos, solo tenemos un ejemplo de suscripción. Pero sí, solo tendremos Kafka porque lo tenemos internamente con clientes. Entonces, si es urgente, también puedes enviarme un mensaje y puedo ayudarte a configurarlo. En realidad, lo más genial sería si puedes configurar un ejemplo de eso, y luego podemos simplemente, podemos simplemente venir y hacer una solicitud de extracción de tu ejemplo y luego tú lo sabrías y todos los demás también lo sabrían. Y tendremos un ejemplo público. Claro, está bien, gracias. Sí, pero es una buena pregunta y solo para ampliarla a todos los demás, GraphQL no solo tiene consultas donde envías algo y obtienes datos. Tiene mutaciones, que es como RPC. Como quiero, ya sabes, activar la función, ya sabes, por ejemplo, como una solicitud POST, ya sabes, como quiero cambiar algo. Así se llama una mutación. Y lo interesante de GraphQL es que puedes enviar una mutación y adjuntarle una consulta. Entonces obtienes un resultado, exactamente como una consulta, lo cual es un concepto muy interesante en sí mismo, pero también hay suscripciones. Suscripciones, tal vez también enlace otra charla que di que da una visión más general al respecto y con muchas visualizaciones realmente interesantes y cosas así. Entonces, espera, déjame encontrarlo. Por lo tanto, las suscripciones de GraphQL son básicamente la idea de que también puedes hacer PUSH, es decir, como que podrías, como que podrías suscribirte a eventos. Como, por ejemplo, cada vez que envío un mensaje a Reddit, quiero suscribirme a una cierta información, como un PUSH o en tiempo real, puedes pensar en mensajes, una aplicación de chat o algo así. Aún puedes usar GraphQL. Como que GraphQL también es bueno en eso. No sé cuánto tiempo tengo, así que no me adentraré demasiado en eso. Pero voy a enviar una charla que di hace mucho tiempo sobre este tema. Hay una lista completa de charlas allí que creo que serían interesantes para la gente. Pero, nuevamente, la idea es que puedes suscribirte a eventos y recibir notificaciones en tiempo real también a través de GraphQL, y también puedes adjuntar una consulta a eso. Puedes decir, cada vez que ocurra un mensaje, quiero obtener esta información. Así es como funciona el mecanismo de GraphQL. Pero nuevamente, con GraphQL Mesh, lo que acabo de mostrarte ahora, el primer paso que mostré en el, como el primer commit que tuvimos, eso es básicamente la configuración. Tienes un servidor Node BFF de GraphQL, y eso llama no a un punto de conexión, sino a un SDK. Por lo tanto, no hay razón para pasar por dos puntos de conexión. Ese SDK se ejecuta como parte del código del servidor Node y llama directamente a esos servicios. Por lo tanto, no hay razón para tener dos puntos de conexión en mi opinión. Sí, quiero decir, si necesitamos manejar la autenticación en el backend de la aplicación web. Sí, es lo mismo. Por lo tanto, es lo mismo. Simplemente no lo agregué al ejemplo, pero nuevamente, llamará a la autenticación y simplemente la pasará al SDK. Y luego, nuevamente, puedes hacer eso. Crea, en mi opinión, digamos, si ya lo tienes hoy, comienza a utilizar ese SDK hoy en este servidor Node para reemplazar las llamadas REST. Eliminará mucho código para ti y lo hará seguro en cuanto a tipos y todas esas cosas. Y al igual que hemos hecho ahora con el taller, puedes ir reemplazando paso a paso el código de tu servidor Node, integrándolo en el SDK hasta el final del día, puedes obtener una aplicación si quieres. No tienes que hacerlo. Entonces, básicamente, el propio servidor Node se convertirá en un GraphQL Mesh.

Y toda la lógica formará parte de GraphQL Mesh y GraphQL Mesh será la cosa que ejecuta el círculo. Sí, sí. Tiene sentido. Porque en ese caso puedo llamar, llamar a GraphQL directamente desde el cliente. Solo, sí. Es extraño que luego todos los sobres en la capa de Node simplemente desaparezcan. Sí, eso es lo que pasa. Se eliminará mucho código, pero es lo mismo. Y también es por eso que puedes usar mesh de muchas formas diferentes. Podrías tener un gateway interno central que conecte todas esas cosas y luego llamarlo directamente. Luego, desde esto, llamas a todo el resto. Pero no necesariamente lo necesitas. Y otra cosa es que puedes tomar todo este mesh y todas las cosas increíbles que acabamos de crear y ejecutarlo como un SDK en el cliente y eliminar completamente el servidor Node y el cliente llamará directamente a los microservicios. Pero nuevamente, entonces, como que es... Si ya tienes un Node y un BFF y tienes los beneficios de rendimiento de GraphQL y todo, no hay razón para hacer eso. Pero mucha gente está comenzando a usar GraphQL Mesh en el cliente antes de tenerlo. Como usan REST en todas partes y quieren usar esta opción agradable y podrían usarla como una forma fácil de entrar en GraphQL básicamente. Y luego, cuando estén listos, toman este SDK y lo ejecutan como un BFF o un gateway o algo así. Sí, solo estoy pensando que, si no hacemos el viaje de ida y vuelta para ir al servidor y luego desde el servidor llamar al punto de conexión de GraphQL, creo que surgirán otras preocupaciones de seguridad porque en ese punto, tu punto de conexión de GraphQL estará de alguna manera disponible en el cliente, al menos la información para obtener datos de él porque activarás solicitudes directamente desde el navegador, ¿verdad? Espera. De nuevo, no lo entendí. Entonces, ahora tienes Node, este servidor Node que básicamente hace alguna autenticación antes de ir y llamar a los microservicios, ¿verdad? Sí. Correcto. Mesh es lo mismo. Solo, la gente lo pregunta, lo pregunta, pero como lo mostré antes, puedes hacer la misma lógica en GraphQL Mesh. Entiendo que mi única preocupación es que si hago la solicitud desde Node, entonces la ubicación de esas API o puntos de conexión se oculta por completo del cliente. Como si estuviera haciendo las solicitudes directamente desde el cliente, el GraphQL expone- Sí, sí, sí, sí, no. Nuevamente, la idea es usarlo directamente como un SDK en el cliente si tus servicios REST ya son públicos, lo que significa que ya tienes un cliente y el cliente llama a REST, ni siquiera sabe qué es GraphQL. Entonces, en ese caso, tus puntos de conexión REST ya están asegurados. Pero en tu caso, si digamos que estás un paso más adelante, tienes un gateway Node que llama a esos diferentes servicios y la parte de autenticación ocurre allí, mesh simplemente reemplaza esto, y en el cliente solo envían consultas GraphQL, no saben qué es GraphQL Mesh en absoluto. Sí, eso tiene sentido.

Pregunta sobre el manejo de errores. Entonces digamos que tenemos varias fuentes, una es, no sé, Open API, otra es, digamos, Drift, y la tercera es, por ejemplo, gRPC. Están arrojando diferentes tipos de errores. Entonces, errores HTTP, errores de Drift, ¿hace mesh algo para consolidar esos errores? Entonces, si estoy usando, digamos, el SDK, no me importa cuál sea el protocolo de transporte que se haya utilizado, pero tengo los errores en la misma forma. Puedo escribir un controlador de errores y capturará todos los errores. No importa qué protocolo se haya utilizado en el fondo.

Esa es una buena pregunta. No tenemos algo listo para usar. Tenemos controladores personalizados que escribimos en las transformaciones personalizadas que escribimos para los clientes que hacen eso hoy. Pero es algo bueno. Quiero decir, también es una pregunta, también es un poco, una vez que te vuelves de código abierto, necesitas encontrar una buena respuesta para todos los casos de uso, lo cual es difícil. Por eso lo dejamos en tus manos. Pero no tenemos algo que lo haga automáticamente, pero sería interesante. Por ejemplo, si tienes un caso de uso así y puedes crear un ejemplo, podríamos iterar sobre eso. Como, ¿cuál sería la mejor manera de convertirlo? Y si pudieras hacerlo de forma pública, como una aplicación de ejemplo, sería genial porque podríamos colaborar en ello. Y luego, creo que también traería muchas preguntas porque, sí, los errores en general en GraphQL, hay muchas preguntas allí. Como, ¿cuál es la mejor manera de hacerlo? Y, pero principalmente también porque hay muchos tipos de errores diferentes. Como, incluso si dejamos de lado el protocolo de la tecnología. Entonces, tal vez sea una buena idea, en realidad, crear un ejemplo para tratar de demostrar tantos tipos de errores y cómo, y tal vez encontrar una respuesta, una buena respuesta para todos ellos. Veremos. Sí, estoy dispuesto a intentarlo. Estoy pensando, GraphQL puede representar los datos de diferentes tipos de fuente de la misma forma. Realmente no importa. Entonces, ¿por qué no hacer lo mismo con los errores? Porque los errores también son datos al final. Podrían ser... Sí, es cierto, pero también hay diferentes tipos de errores. Creo que, con diferentes necesidades. Y algunos de ellos, puedes pensar en ellos como datos, y algunos de ellos, puedes pensar en ellos como errores de red, y algunos de ellos son simplemente un fallo sin... Sí, es una cuestión de cómo representarlo. Hay una gran pregunta en general, cómo representar errores en GraphQL. Y esa pregunta es difícil, porque hay muchos tipos de errores. Algunos de ellos son errores de producto. Algunos de ellos son errores de datos, y también el propio producto debería tener la opción de cómo responder a diferentes tipos de errores. Entonces, si profundizas un poco en eso, ves que hay opciones de unión, y luego hay rutas de error y todo tipo de técnicas diferentes, y es una pregunta en la que creo que el producto a veces debe decidir. Pero sí, es bueno tener al menos algunos valores predeterminados, creo que eso sería bueno. Creo que será interesante, sí. Porque estoy pensando, digamos que alguien está usando el SDK generado por otro equipo, realmente no sabe qué protocolo se usó en el SDK, por lo que pone un try catch alrededor del await, pero realmente no sabe qué tipo de errores puede capturar. Sí, es cierto, es completamente obfuscado, lo cual es realmente genial, porque el SDK no... Entonces la pregunta es si tienes esto en el esquema, todos los tipos de errores, y puedes representarlo de una buena manera, entonces sí, creo que será interesante. Pero sí, quiero ver más casos de uso. Es posible, creo, sí. Sí, creo que si podemos darte uno, si no te importa configurar algunos, un par de ejemplos de esto, sería realmente genial pensar juntos al respecto. Como que no tenemos nada automático ahora, pero es, sí, puedo pensar en todo tipo de formas diferentes de verlo, por lo que sería genial ver ejemplos. Y creo que también sería valioso para todos. Si no te importa, si tienes tiempo, entonces hagámoslo. Sí, tengo en mi agenda revisar mesh como un SDK, porque tenemos nuestro propio SDK construido internamente, que también hace este manejo de errores, uno genérico. Realmente no importa cuál sea el protocolo de transporte, solo tienes algunos errores genéricos, así que intentaré hacerlo con la API de mesh. Veamos qué sale. Sí, sí, suena súper interesante, gracias. Es realmente genial, sería genial comparar los SDK. Es bastante agradable. Nuestro SDK es muy opinado y realmente está construido para un caso de uso. No se puede comparar, pero intentaré reconstruirlo con el SDK de mesh, así que. Genial, gracias. ¿Más preguntas? Creo que tenemos como un minuto antes de que termine, pero siéntanse libres de preguntar. Solo quiero decir gracias por su tiempo. Fue una gran conversación que tuvimos y fue muy agradable obtener todas las preguntas respondidas. Definitivamente me diste mucha, nos diste a todos mucho contexto al respecto, una mejor comprensión. Gracias por tu tiempo. Gracias, muchas gracias. Fue genial. Gracias. Y nuevamente, siéntanse libres de comunicarse. Siempre estoy disponible y siempre buscamos más casos de uso y más preguntas. Y como dije, no hay preguntas estúpidas. Todas las preguntas nos ayudan a comprender mejor lo que las personas necesitan del código abierto. Así que sí. Realmente siéntanse libres de contactarme en cualquier cosa, podría ser mi correo electrónico en mi GitHub o a través del Discord que tenemos, o simplemente el chat en nuestro sitio web que les mostré. Sí. Entonces, si hay algo más, creo que cerraré aquí. Muchas gracias. Y sí, hay... Esto es solo una cosa y hay mi charla en la conferencia real, que espero que también les guste. Hablo allí sobre más cosas. Sí. Así que gracias por quedarse y escuchar. Y nos vemos pronto. Gracias por el trabajo. Gracias. Adiós a todos. Sí. Adiós.