Todo lo que necesitas para preparar tu servidor GQL para producción

Así que soy Uri. Soy miembro de un grupo llamado The Guild. ¿Cuántos de ustedes han oído hablar de The Guild? ¿Nadie? Yo sí. Bueno, genial. Así que solo compartiré un poco. The Guild es un grupo de desarrolladores de código abierto. Personalmente, comencé este grupo hace un par de años. Solía trabajar en Apollo. De hecho, estaba en el equipo que comenzó Apollo. Construimos otra cosa llamada Meteor. Era un marco de JavaScript, y pensamos en cuál sería la próxima versión de Meteor. En aquel entonces, fue cuando Facebook abrió GraphQL. Así que pensamos que tal vez la próxima versión de Meteor se basaría en GraphQL. Y así es como comenzamos con Apollo Client, Apollo Server y la biblioteca de herramientas de GraphQL, entre muchas otras cosas que todavía son populares hoy en día.

Así que comencé allí en Apollo, y luego después de un tiempo, decidí construir otro grupo que está estructurado de manera un poco diferente para construir un código abierto sostenible. Las bibliotecas se mantendrán bien durante mucho tiempo, durante muchos años, y no habrá presión de, como, menos presión de vender un producto, sino más bien hacer un código abierto sostenible. Entonces, las herramientas que construimos hoy son el Generador de Código GraphQL del que hablaré un poco hoy, GraphQL Mesh, Envelope, Inspector de GraphQL, Módulos de GraphQL. Muy nuevo, asumimos GraphQL Yoga, si algunos de ustedes han oído en mi charla, también estoy haciendo la presentación principal para GraphQL Galaxy, y en la presentación voy a anunciar algo al respecto, así que lo sabrán incluso antes que todos. Básicamente, hoy en día somos el grupo de código abierto más grande en GraphQL, y también hacemos mucho trabajo que está fuera del ámbito de GraphQL, como con OpenAPI y todo tipo de otras APIs, como JSON Schema, grpc, todo tipo de otras cosas, así que también trabajamos allí, así que eso es un poco sobre nosotros, y cómo trabajamos es que trabajamos con clientes, con empresas. Construimos herramientas de código abierto y luego consultamos, y también les ayudamos a introducir las herramientas y mejorar las herramientas, y cosas así, por lo que todas las herramientas se construyen por una necesidad real, como que no hacemos código abierto de una herramienta que ninguno de nuestros clientes está utilizando en producción, todo el código abierto es algo que usamos en producción, por lo que puedes saber que puedes confiar en ello y sabes que hay una necesidad real para ello, y no es algo que te estamos vendiendo, o lo hacemos por razones de popularidad, o cosas así, así que eso es un poco sobre The Guild, cada miembro de The Guild es un miembro que realmente contribuyó al código abierto antes de unirse a The Guild, y a veces puede ser difícil para ti encontrar nuestras bibliotecas, porque todas las bibliotecas están bajo los nombres de las personas, y no bajo el nombre de The Guild, creemos que este es un mejor modelo para un código abierto más sostenible, es muy raro, no es algo muy común, pero así es como lo hacemos hoy en día.

Mencioné The Guild al principio, construimos muchas herramientas diferentes, no hablaré mucho sobre eso, pero solo que todas nuestras herramientas se construyen de una manera específica, tanto en la forma de código abierto que mencioné al principio, como también completan una plataforma completa, por lo que la idea es que te proporciona todo lo que necesitas desde el backend hasta el frontend para construir una aplicación, pero puedes usarlos completamente por separado, no te estamos obligando a usarlos, no es una plataforma bloqueada por proveedor, cada herramienta se puede usar por sí misma, tratamos de descomponer estas herramientas en las piezas más pequeñas que podemos, para que sean lo más flexibles posible. Y menciono esto ahora porque creo que es importante y también es parte de las razones por las que creamos algunas herramientas nuevas que presentaré hoy, porque creemos que de esa manera realmente podemos resolver las cosas mejor. Y así, hablaré un poco sobre eso y también haré mi introducción a las herramientas. Compartiré un tutorial contigo que, en mi opinión, está mejor estructurado en comparación con otros tutoriales de GraphQL que existen porque separa algunas cosas. Así que llegaré a eso pronto. Pero volvamos a lo básico de GraphQL. Nuevamente, todos aquí saben probablemente un poco sobre qué es GraphQL. Es un lenguaje de consulta. Puedes describir los datos que deseas consultar en un esquema. Esos datos pueden ser cualquier dato. Esa es la parte interesante de GraphQL. Es un lenguaje de consulta, pero a diferencia de SQL, donde necesitas estructurar tus datos y tus tablas de cierta manera, aquí puedes crear básicamente un esquema, consultar ese esquema y obtener resultados predecibles. Pero ese esquema puede describir cualquier dato. Puede ser algo que se superponga a una API REST, lo cual es muy común. Puede ser solo un archivo. Puede ser una base de datos. Puede ser cualquier dato que tengas, una hoja de cálculo de Excel, cualquier cosa. Así que eso es interesante porque ahora puedes comenzar a construir gráficos de datos, de cualquier dato que tengas. Y también puedes superponerlo en lugares que, digamos, que tal vez no hayas pensado antes. Espero poder tocar eso de nuevo. Estoy omitiendo este ejemplo. Es solo un ejemplo con REST, donde puedes consultar cualquier cosa, si quieres obtener una lista de chats y cosas así, entonces vas a consultar de un lado a otro y tal vez necesites múltiples solicitudes y respuestas. Y puedes construir puntos finales REST personalizados, ¿verdad? Así que no siempre es cierto. Puedes construir el punto final REST perfecto de GraphQL y aún así obtener exactamente lo que quieres. Pero eso significa que ese trabajo se realiza en el backend. Con GraphQL, el cliente simplemente puede describir lo que quiere y obtener exactamente lo que quiere. Los viajes de ida y vuelta adicionales son algo de lo que mucha gente está hablando como algo que GraphQL puede resolver y también el exceso de datos, ¿verdad? Como puedes tener un punto final y en este caso es un punto final específico para repositorios en GitHub y vas a obtener toneladas de información que tal vez no necesites. Así que a través del cable donde eso importa, vas a obtener mucha información. Esto es solo algo que copié de graphql.org. Por cierto, ahora estamos reconstruyendo la infraestructura de graphql.org y estamos tratando de convertirla en el mejor recurso. Entonces, si alguno de ustedes está interesado en la documentación y en ayudar a su equipo a incorporarse y cosas así, espero hacer de graphql.org el mejor lugar para ir y aprender sobre GraphQL y encontrar todos los recursos y todo lo que estoy diciendo ahora, espero que no necesiten hablar conmigo. Solo pueden ir a graphql.org. Así que si alguno de ustedes está interesado en ayudar, este proyecto no se movió mucho durante muchos años y ahora lo estamos cubriendo y espero que podamos hacer de graphql.org un mejor sitio web. Sí, entonces, ya saben, GraphQL, lo que todos están mostrando es que puedo consultar solo los datos que necesito y puedo enviar una consulta y obtener un resultado. Hoy vamos a hablar también sobre cosas más avanzadas. Un poco sobre, ya saben, tal vez una ilustración de cómo funciona. Así que tenemos un cliente y digamos algunas fuentes de datos y en el medio ponemos, llamémoslo el Motor de GraphQL en lugar de un servidor de GraphQL. Y espero que más adelante entiendan por qué lo llamo un motor y no un servidor. Entonces, y podemos describir los datos de todas estas fuentes de datos utilizando un esquema. Así que escribimos ese esquema. Hay muchas formas diferentes de ejecutar ese esquema. También podemos hablar hoy sobre diferentes formas de escribir un esquema, ese esquema podría, podría escribirse simplemente. Y ese esquema manual podría escribirse en lo que se llama SDL. Así que el lenguaje real de GraphQL, lo que puedes ver aquí a la izquierda, pero también se escribirá con código. Así que podrías escribir como clases que representan estas estructuras de datos y hay ventajas y desventajas o objetos que representan estas estructuras de datos. Y hay ventajas y desventajas para ambos enfoques. Y también hay diferentes bibliotecas para todos estos enfoques. Si estás interesado en eso, avísame porque tengo muchas opiniones al respecto. Así que describimos el esquema y luego el cliente básicamente puede consultar algo que desea, digamos en este caso, el usuario con AB2 y un nombre, y luego el motor de GraphQL obtendría esa consulta y la ejecutaría de la manera más eficiente que pueda. Así que irían a buscar tal vez al usuario y luego extraerían del objeto de usuario el nombre y nos enviarían lo que realmente necesitamos.

Y si queremos más información sobre el usuario, digamos que enviamos una consulta más grande, entonces tal vez el servidor nos devuelva el objeto de usuario y luego el motor gráfico realmente buscará en paralelo el nombre y los mensajes si puede ver que puede hacerlo. Y luego tal vez el contenido pueda venir de una fuente completamente diferente, pero la forma en que lo modelamos, lo modelamos como el cliente ve los datos, quiere ver los datos y lo modelamos como mensajes y su contenido se ve básicamente igual. Es parte del objeto de mensajes, por lo que el cliente recibe un solo resultado y no importa qué tan complicado sea el servidor o cuántas fuentes de datos o cuántos servicios tenga su backend. Para el cliente, obtienen la representación de los datos que esperan, lo cual es un punto importante, creo, cuando hablaremos un poco sobre GraphQL Mesh, del cual hablaré, espero poder hablar hoy.

Verás que hay dos filosofías diferentes de cómo describimos el esquema de los datos. El esquema que básicamente es todas nuestras fuentes de datos juntas en un gráfico o el esquema que realmente necesita el cliente. Y espero mostrarte hoy que esos podrían ser dos esquemas diferentes. Así que, sí, esa es una ilustración básica de cómo funciona GraphQL, muy básica. Ahora profundicemos un poco más en eso solo para entender, porque para mí, cuando hablo de GraphQL, en realidad solo veo que hay una función. Así que mostraré lo que esa función realmente es y lo que esa función realmente hace.

Cuando describimos los datos, también escribimos resolutores. Los resolutores son la forma de decirle a GraphQL cómo obtener cada campo. En este caso, tenemos una función. Digamos que queremos el nombre del usuario. Básicamente creamos la función para saber cuál es el objeto que va a recibir como entrada. Sabemos cuáles son las entradas que se están obteniendo en la función. En nuestro caso, es como un objeto de usuario, digamos. El padre, el resolutor padre, el punto de entrada para el gráfico. Y luego podemos ejecutar cualquier código que queramos. Es básicamente una función. Así que podemos hacer lo que queramos en esa función, incluyendo llamar a otro servidor o cualquier cosa, y necesitamos devolver una cadena porque hemos definido una cadena. Así es como se hace cuando creamos un servidor GraphQL o un motor GraphQL.

Ahora, todo lo que verás en esta diapositiva es básicamente una diapositiva en la que intento explicarte el trabajo básico de lo que la función GraphQL está haciendo internamente. Así que todo esto, siempre, cuando muestro esa diapositiva, les pido a las personas que piensen mientras ven esa diapositiva, ¿dónde escriben el código hoy? Entonces, la función GraphQL básicamente obtiene estas funciones de resolución que se crearon en el esquema. Luego crea, y el otro argumento que recibe es una consulta. Realmente, piénsalo como una función que se llama GraphQL y recibe dos variables, dos entradas. Una se llama esquema ejecutable, que son las definiciones que vemos a la izquierda, y sus funciones. Y el otro argumento es la consulta que puede cambiar entre diferentes llamadas. Y luego lo que hará la función GraphQL es que obtendrá ese id 10 que obtuvimos en la parte superior, en la consulta, y ejecutará el primer cuadro, la primera función. Y obtendrá un resultado. Ese resultado sería un objeto de usuario, digamos. Ahora sabe por el crédito que necesitamos un nombre y un mensaje. Entonces, lo que GraphQL hará es tomar los cuadros y los ejecutará en paralelo porque puede, porque ambos de estos cuadros realmente requieren el mismo valor padre. Así que los ejecutará en paralelo. Un cuadro, el nombre nos dará la cadena, hemos terminado. Entonces lo pondrá en el lugar correcto. Luego los mensajes, en realidad obtenemos tres objetos de mensajes diferentes. Y para cada uno de ellos, queremos el título y la fecha. Entonces, ahora el motor GraphQL realmente ejecutará todos estos diferentes cuadros para todos los resultados diferentes. Y cuando los resultados lleguen, porque todo esto es asíncrono, cada cuadro aquí es una función asíncrona. Entonces podemos llamar a un punto final remoto o algo así. Cuando lleguen los resultados, colocará todos los resultados en la estructura correcta en el lugar correcto y nos devolverá los resultados. Esa es la función GraphQL.

Ahora creo que, lo que vimos aquí es que GraphQL no solo minimiza los datos que enviamos a través de la red o algo así, sino que en realidad GraphQL automatiza gran parte del trabajo de datos que hacemos nosotros mismos, tal vez en código u otros medios. Entonces GraphQL espera y orquesta todas las diferentes llamadas de red que necesitábamos hacer y todas las diferentes acciones que necesitábamos tomar para obtener los datos que queremos. Y luego también da forma a los datos de la manera que queremos. Y creo que ese es el mayor beneficio de GraphQL en la mayoría de los entornos. En la mayoría de los entornos, no se trata necesariamente de ahorrar algunos bytes en la red, sino de automatizar gran parte del trabajo de datos que hacemos de todos modos. Y el trabajo de datos se realiza de muchas formas diferentes. Puede hacerse en el cliente, puede hacerse en un servidor, incluso puede hacerse en servicios de análisis de datos y cosas así, que consultan muchos servicios diferentes de muchas fuentes de datos diferentes, obtienen los datos que desean y luego hacen algún análisis. Por lo tanto, todos estos podrían beneficiarse potencialmente de GraphQL. Esos son algunos de los beneficios que creo que tiene GraphQL. Por cierto, si es muy básico, avísame y si tienes preguntas o quieres llevarme en otras direcciones mientras estoy diciendo esto, también avísame.

Muchas veces, cuando vamos a una empresa y comenzamos a trabajar con ellas y realmente queremos implementar GraphQL en una solución y llevarlo a producción lo más rápido posible, pensamos, bueno, ¿por dónde deberíamos empezar? En mi opinión, el mejor y más fácil lugar para comenzar, y realmente creo que cuanto antes obtengas el caso de uso y vayas a producción, mejor. En lugar de preparar demasiado, debes ir a producción lo más rápido posible con este caso de uso muy simple, y luego verás a qué te enfrentas realmente.

Por supuesto, puedes prepararte y podemos hablar de ello hoy, pero aún así creo que todos los talleres del mundo no te prepararían tanto como simplemente probarlo. Nuestro objetivo siempre es, ¿cuál es la forma más rápida de llevar GraphQL a producción? Y por eso te pregunté en la diapositiva anterior, ¿dónde crees que ocurre esa lógica que viste que GraphQL estaba haciendo hoy, dónde crees que está ocurriendo hoy?

Te daré un ejemplo de dónde muchos de las aplicaciones con las que trabajamos, ¿dónde tenían esa lógica antes de que llegáramos? La mayoría de ellas tenían una aplicación que usaba una API REST. Esas API REST se construían de manera muy genérica. Así que eran muy RESTful y bastante ordenadas. Eso significaba que, por un lado, era muy fácil navegar por la API. Por otro lado, el cliente realmente tenía que hacerlo. Y como demostré al principio, tenía que buscar un par de puntos finales diferentes. Luego tomar los datos y tal vez eliminar los datos que no necesitaban. Luego tal vez combinarlos de otras formas y luego estructurarlos de la manera que realmente necesita la interfaz de usuario. La aplicación realmente necesita. Gran parte de ese trabajo se realiza en el código que se ejecuta en el cliente hoy en día.

Entonces, lo que hacemos muchas veces, y por eso lo llamo el motor o función de GraphQL en lugar de un servidor de GraphQL, es que tomamos ese trabajo y tomamos todo lo que te mostré antes, y simplemente colocamos GraphQL como una función en el cliente. Entonces, lo que ves aquí es que todavía estamos en el cliente y todavía estamos orquestando y haciendo todo el trabajo, pero ahora los componentes de la interfaz de usuario pueden consultar en GraphQL los datos que necesitan. Las consultas son muy similares a la estructura que necesita la interfaz de usuario. Y luego GraphQL realiza mucha automatización. Básicamente, podríamos eliminar mucho del código manual que se realiza en el cliente y simplemente utilizando GraphQL, por ejemplo, o cualquier cliente que puedas tener. Donde ejecutas esa lógica a través de GraphQL y sobre la red, seguimos utilizando las mismas API antiguas que teníamos antes.

Ahora, eso es interesante porque creo que también es bueno por muchas razones diferentes. La primera, como dije, el objetivo aquí es llegar a producción lo más rápido posible. Entonces, es más fácil en términos de convencer a las personas en tu empresa, ¿verdad? No hiciste un cambio arquitectónico enorme. Simplemente instalaste, digamos, si estás trabajando en JavaScript, simplemente instalaste otro paquete de NPM. No hiciste nada. No agregaste un servidor, no agregaste un gateway, ninguna de estas cosas. Pero ya comenzaste a usar GraphQL y ya comenzaste a eliminar mucho código manual. Y lo que también comenzaste a hacer es modelar en un esquema, en un esquema de gráfico, los datos que tu aplicación necesita. Y eso es lo importante aquí. Entonces, la segunda parte importante, como dije, la primera es llegar a producción lo más rápido posible. La segunda es comenzar a modelar los datos según lo que tu aplicación necesita y no necesariamente según lo que tu servidor expone o cómo se exponen tus fuentes de datos. Ahora, eso es algo poderoso porque te daré un ejemplo. Aún tenemos un código abierto, pero si alguien aquí quiere comenzar a probarlo, puedes intentarlo porque lo acabamos de probar en un par de clientes nuevos. Acabamos de crear un complemento de Figma-GraphQL-script. Hay uno antiguo que alguien construyó hace muchos años. Así que ahora construimos uno nuevo. Y la idea es que puedas ver el diseño. Puedes ver los diseños de tu aplicación y luego construir tus consultas de GraphQL en función de eso. Y creo que esa es una mentalidad importante porque ahora creas un esquema que realmente representa los datos de tu aplicación y es posible que ni siquiera sepas si los datos realmente existen y dónde y cómo los expuso tu servidor. Pero eso es, creo, cómo vemos que se construyen los mejores esquemas de GraphQL que sirven a los productos. Se construyen desde la perspectiva del producto. Eso es, ya sabes, lo... Así que la segunda parte, lo importante para comenzar, es ayudarnos a ordenar eso, es que por definición describimos los esquemas de GraphQL como lo que la aplicación necesita y no necesariamente como un esquema genérico o impulsado por el servidor. Es un esquema impulsado por el producto. Así que ese es otro beneficio que obtenemos de este enfoque.

Ahora, nuevamente, esta cosa es algo que básicamente orquesta nuestro flujo de datos. Nos explica qué son los datos. Hay un esquema en un esquema muy claro que es fácil de compartir y mostrar a todos lo que la aplicación necesita. Y ahora podemos averiguar dónde y cómo hacer el trabajo de orquestación y automatización. Y luego, más adelante, podríamos tomar el mismo código, incluso si lo escribimos en JavaScript. Podemos llevar casi el mismo código y casi la misma función y moverlo al gateway, por ejemplo. Y ahora también obtenemos los beneficios de las llamadas de red y cosas así. Por cierto, si vuelvo a este estado, alguien mencionó, por ejemplo, así que aquí, tal vez no obtenemos llamadas de red más eficientes y cosas así. Eso es medio cierto porque alguien mencionó el problema N más uno en los cargadores de datos. Todos saben cómo usar los cargadores de datos en el servidor, pero aquí podemos comenzar a usar los cargadores de datos en el cliente. Entonces, de hecho, podríamos obtener formas muy eficientes de consultar nuestras fuentes de datos, incluso aunque sigamos ejecutando en el cliente. Sí, eso es solo una cosa que vemos mucho cuando vamos a producción. Permíteme omitir esto. De acuerdo, estoy pasando por muchas cosas. Y nuevamente, sí, avísame, sí, si tienes alguna pregunta o algo así. Y la otra cosa es que hablé un poco sobre estos resolutores, estas funciones que GraphQL ejecuta al final. Y porque definimos el esquema, sabemos cuáles son las entradas y las salidas de cada uno de estos resolutores. Eso significa que podríamos generar en el lenguaje que queramos, podríamos generar usando code, GraphQL code generator. Podríamos generar automáticamente las entradas y salidas de estas funciones. Así obtenemos una definición completamente, si estamos usando TypeScript, por ejemplo, o Java o .NET, no importa. No necesitamos crear manualmente estos tipos. Podemos crear automáticamente estos tipos y tener estas funciones completamente tipadas cuando se las entregamos a una persona para que ejecute sus tareas, ¿verdad? Es una definición muy clara de cuál es la tarea y los tipos que vamos a obtener y los tipos de los resultados que esperamos obtener de estas funciones. Así que es una idea muy, muy poderosa. Así que si alguno de ustedes no está usando GraphQL Code Generator, muchas personas conocen GraphQL Code Generator para el frontend, lo que significa que puedes tomar la consulta, entender a partir de la consulta los tipos que vas a obtener y luego generar los tipos y tal vez incluso SDK para consultar el servidor. Aquí estamos usando GraphQL Code Gen en el backend, en los propios resolutores. Como te mostraré, si vas al sitio web de Code Gen, tal vez ya sepas todo esto, pero en el sitio web de Code Gen, verás que tenemos este playground aquí.

Aquí hay una lista de todos los diferentes plugins que tenemos en Code Gen. Hay muchos lenguajes diferentes, muchos casos de uso diferentes, pero también los etiquetamos por front-end y back-end, ¿verdad? Entonces, si vemos aquí, tomemos esto, obtenemos el esquema y también obtenemos las consultas. Aquí vamos a generar los tipos de las consultas, lo que realmente vamos a obtener de la consulta en fragmentos específicos. Pero también podemos ir al lado del back-end y generar, como dijimos aquí, la firma del resolutor. Básicamente, ¿cuáles son los tipos de las funciones que realmente vamos a ejecutar? Sí, por cierto, esto es algo nuevo, acabamos de reconstruir el sitio web y ahora hay un centro de plugins donde puedes explorar todos los diferentes plugins aquí y cada plugin tiene un sitio web diferente, como una página diferente, y puedes etiquetarlos con cualquier etiqueta que quieras. Si quieres morado y ver todo lo que funciona con morado. Sí, de todos modos, eso es genial. Es algo que deberías usar si estás usando GraphQL. Te ayuda a comprender los tipos y escribir código y validarlo mientras lo escribes. Y otra herramienta que probablemente deberías usar si ya agregué, ya detuve esta cosa es GraphQL ESLint. Así que esa es otra herramienta relativamente nueva que tenemos. Hay un par de otras bibliotecas relacionadas con GraphQL y ESLint. Creo que Apollo tiene esta biblioteca, por ejemplo. Si la estás usando, deja de usarla. No está mantenida. El último commit fue en 2020. Fue por Renovate. Es muy antigua y hay muchas razones por las que no es tan buena. Hay otra. Esta está mantenida por nosotros. Está muy actualizada. Sí, puedes ver el commit, el último commit fue hace tres horas. Y también lo lanzamos hace tres horas. La idea aquí es que está construida de una manera mucho más inteligente. Y la idea aquí es que valida. Tiene muchas, muchas reglas entre las que puedes elegir. También agregamos conjuntos de reglas recomendadas, tanto para el frontend, es decir, para consultas, como para el backend. Y lo bueno es que está separado por reglas. Resaltará todas estas cosas mientras trabajas en tu base de código, pero también puedes crear reglas personalizadas. Muchas empresas con las que trabajamos tienen todo tipo de mejores prácticas o cosas así en las que trabajan y que quieren hacer cumplir aquí y necesitan enseñar y tienen documentación para ello aquí, simplemente puedes hacer cumplir eso con tus propias herramientas. Sí, eso es. Sí, y cada plugin tiene, de hecho, como... Sí, hay cosas recomendadas. Pero luego, y hay cómo crear plugins y cosas así. Pero bueno, aquí están los documentos, puedes ver que tienes muchas cosas diferentes, como todo esto se genera a partir del código fuente. Sí, son bibliotecas relativamente nuevas. Entonces, muchas personas todavía no están al tanto de ellas. Y luego hay muchas reglas entre las que puedes elegir aquí. Y puedes crear tus propias reglas personalizadas y luego también compartirlas con la comunidad. Y algunas reglas son para el frontend en realidad. Por ejemplo, como necesitan tanto los documentos, como las consultas y las mutaciones y el esquema. Y en realidad, podrían advertirte si, digamos, en el esquema, por ejemplo, hay tipos no utilizados. Por ejemplo, puedes decir, en el esquema, este tipo no se utiliza, por ejemplo, en cualquier parte del frontend, si quieres. Sí, así que hay buena documentación para todo. No sé, simplemente, volveré a mis diapositivas. Pero si no has oído hablar de GraphQL ESLint, anótalo. Creo que es una gran herramienta. Entonces, ahora tenemos resolutores. Esos resolutores pueden estar en el frontend o en nuestro gateway. Y usamos GraphQL Code-Gen y están tipados, o tal vez usamos el enfoque Code-First, del que también tengo algunas opiniones sobre las diferentes bibliotecas. Ahora probablemente vamos a admitir una nueva biblioteca en eso. Por cierto, alguien mencionó que está usando Apollo server. Entonces eso significa que básicamente estás usando, probablemente estás usando, como el enfoque schema-first, lo que significa que estás usando GraphQL tools, que también es nuestra biblioteca. Así que solo una nota aquí, si estás usando Apollo server, te recomiendo importar, cuando crees tu esquema ejecutable, como ejecutas tu SDL y lo adjuntas a los resolutores y creas un esquema ejecutable, te recomiendo encarecidamente que importes esa función. Te lo mostraré. Desde la función makeExecutableSchema que probablemente estás usando cuando usas Apollo server, te recomiendo que uses esta de GraphQL tools schema y no de Apollo server. La razón es que Apollo server simplemente envuelve esta función, esta biblioteca. No hace nada más, pero Apollo server envuelve esta función para ti, lo que puede parecer conveniente, pero también significa que están desactualizados. Seguimos lanzando nuevas versiones de esta cosa por muchas razones diferentes, actualizaciones de seguridad y dependencias, muchas nuevas capacidades y también nuevas, lo hacemos más eficiente y todo tipo de cosas así. Y Apollo no sigue tan a menudo y no actualiza su biblioteca tan a menudo. Entonces, Apollo ahora también en sus problemas, si ves, y ves los últimos comentarios, también te están recomendando que uses en realidad makeExecutableSchema de GraphQL tools schema y luego lo ajustes a Apollo server. Así que esa es solo una recomendación. Y esto es, por cierto, si estamos hablando de GraphQL tools, GraphQL tools tiene muchas, muchas cosas diferentes. Y realmente hemos invertido recientemente en una documentación muy exhaustiva sobre GraphQL tools. Así que ahora te recomiendo encarecidamente que revises muchas de las cosas aquí, incluso si no las estás... Es solo, hay una descripción general de muchas herramientas diferentes que estamos construyendo aquí. Y creo que es valioso incluso solo para tener conocimientos generales sobre GraphQL. GraphQL tools es otra biblioteca que mantenemos. Como dije, aquí, puedes ver en cualquiera de nuestros sitios web, puedes ver aquí todas las otras herramientas diferentes que desarrollamos y las repasaremos con suerte para explicar por qué las desarrollamos y por qué te recomendamos que las uses.

De todos modos, lo que quiero decir es que si estás utilizando las herramientas de GraphQL, deberías usarlas junto con el generador de código y el generador de código gráfico para generar los tipos. Pero también puedes utilizar el enfoque Code First, ¿alguien aquí utiliza el enfoque Code First? Necesitas, si lo haces, necesitas hablar porque creo que no puedo ver. Antes lo hice en un proyecto, pero el último fue el enfoque Code First. ¿Qué biblioteca utilizaste? Apollo server. Apollo server, pero ¿qué biblioteca utilizaste para definir el esquema en sí? Como, hay como tipo GraphQL, hay un Nexus GraphQL, todo tipo de cosas así. ¿Recuerdas tal vez? Creo que no, usé las herramientas de Apollo para todo hace dos años y, con el enfoque Code First, estaba usando NestJS. Ah, NestJS, sí, sí, sí. Sí, sí. Entonces, NestJS es otro framework. También puedo compartir mi opinión, pero será más tarde. Bueno, el enfoque Code First de NestJS es bastante similar al tipo GraphQL. Significa que estás escribiendo código similar a eso, ¿probablemente, verdad? Como, se parece un poco a eso. Tenemos clases y... Sí. Sí. Entonces, sí. NestJS en realidad dependía de tipo GraphQL y luego, por alguna razón, decidieron moverse a su... Lo bifurcaron por alguna razón, ahora importas todas estas cosas de NestJS GraphQL en lugar de tipo GraphQL. No estoy seguro exactamente por qué. Sí. Entonces, el enfoque Code First tiene beneficios y hay muchas soluciones diferentes como Nexus también. Ahora, la mayoría de las veces... Algunos de los beneficios son que no necesitas escribir SDL de forma independiente... Obtienes seguridad de tipos y no necesitas ejecutar código para obtener la seguridad de tipos que necesitas. No es que piense que ejecutar código sea difícil, pero a algunas personas les molesta. Hay muchas soluciones diferentes, por cierto, Nexus, que es otra forma famosa de escribir tus esquemas Code First, en realidad utiliza Code Gen en su interior. Así que no es que no utilicen Code Gen, pero también hay otras soluciones. Hay GQTX y Geographical. Y empezamos a investigar esto y, de hecho, si optas por ese enfoque, creo que GQTX y Geographical son considerados mejor mantenidos que las otras soluciones. Puedes ver aquí que se utiliza Geographical con Apollo server. Básicamente construyes tu esquema de esa manera y luego simplemente envías un esquema ejecutable a Apollo server. También me pediste que recomendara algunas herramientas. Ahora estamos en proceso de trabajar probablemente con la persona que escribió Geographical y probablemente haremos una comparación entre todos los enfoques Code First, como Geographical, GQTX, NestJS, Nexus y TypeGraphQL, y probablemente haremos... sí, algo así como encontrar la mejor solución aquí. Ahora, hay otra cosa que tal vez pueda hablar de ella aquí, pero aún no está disponible, pero quiero compartirla contigo. Si estás pensando, tienes esta pregunta sobre qué debería hacer, y hay otra cosa que debes tener en cuenta. Déjame tratar de encontrarlo. Solo un segundo. Sí, esto. Compartiré el enlace en el chat. Oh, bien. Perdí al chatbot. Zoom, no sé cómo... De acuerdo. Solo estoy yendo por aquí. También dime si algo está mal. TypeScript ha añadido en realidad muchas características nuevas recientemente y ahora puedes empezar a utilizar el analizador de TypeScript real para hacer cosas realmente geniales. Lo que esta PR está haciendo, y hemos estado experimentando con ello durante un tiempo, pero en realidad, desde TypeScript 4.5, es utilizable. Simplemente alimentamos el esquema primero, básicamente el esquema gráfico, lo que ves aquí, las profundidades de tipo son solo GraphQL, por lo que el tipo de consulta es una cadena completa. No es Code First, es Schema First. Pero TypeScript entiende los tipos. Entonces, en este caso, en realidad obtenemos los beneficios de Code First. No necesitas ejecutar un generador o algo así, es algo intermedio. En realidad, podrías escribir los tipos de los tipos. Pero debido a todas las nuevas características de TypeScript, SDL1 tiene tipos. Ahora podemos decirle a los resolutores que simplemente utilicen los tipos inferidos de esto y obtener esto completamente tipado. Esto es realmente genial. Puedes ver que Vatan hizo algunas actualizaciones recientes aquí. Así que estamos muy cerca de lanzarlo. Y esto es realmente emocionante. Probablemente después de hacer eso, vamos a publicar una nueva publicación de blog. En primer lugar, cubriendo, tal vez serán dos publicaciones de blog separadas. Veremos, pero primero, probablemente trabajaremos con el chico que escribió GraphQL. Así que vamos a ordenar un poco el enfoque Code First, aunque hasta ahora nos hemos centrado principalmente en las herramientas gráficas, porque también creemos que en el enfoque Code First, había algunas bibliotecas que no están tan bien mantenidas. Nexus fue muy popular. Prisma lo promovió durante mucho tiempo y luego dejó de mantenerlo durante un tiempo. Así que también queremos intervenir allí y crear mejores soluciones. Y queremos exponer esto, solo un segundo, hay una tormenta realmente loca aquí y mi ventana se abrió sola. Dame solo un segundo. Lo siento por eso. Sí, en Israel no hay muchos días de invierno, pero cuando los hay, hay muchas tormentas.

Espero que no escuches mucho ruido mientras hablo. Sí, escucho todo tipo de cosas volando alrededor de mi edificio. De todos modos, esto es solo un poco de antecedentes para este debate de código primero, esquema primero que muchas personas quieren que comente, así que sí.

Un segundo. Ok, espera. Zoom es extraño, solo un segundo. Ok, volviendo a la parte del resolvedor. Nuevamente, estoy cubriendo aquí muchos temas. Espero que estés tomando notas. Espero que me detengas y me hagas preguntas sobre todo esto.

Entonces, comenzamos creando un esquema ejecutable de GraphQL, ya sea código primero o esquema primero, y luego describimos los datos desde la perspectiva del cliente o del producto, eso es una parte importante. Y ahora, cuando entramos en la implementación, en los resolvedores, tenemos esos resolvedores con tipos, ya sea código primero o esquema primero, gracias a los generadores de código de GraphQL. Pero lo que generalmente hacemos a continuación es llamar a las fuentes de datos subyacentes. Esa es la forma más común en que las personas trabajan en esto. Y en ese punto, es donde, cuando las personas comenzaron con GraphQL, es donde se quedaron. Es como, está bien, tengo esto de GraphQL funcionando y disfruto los tipos de GraphQL y disfruto el código. Y tal vez si soy un usuario más avanzado, eso es genial. Pero luego, después de obtener eso y tal vez poner esto en producción, algunas cosas, las primeras cosas que creo que las personas ven son que realmente disfrutan la experiencia de GraphQL, pero en los resolvedores cuando llamo a una llamada remota, digamos que llamé a mis fuentes de datos REST, que es el caso de uso más común, aún no tengo tipos para esa llamada remota, ¿verdad? Como que no cambiamos nada en nuestros backends. Como, digamos que es una API REST y tal vez no tengamos una definición de swagger o algo así. O tal vez sí y está actualizada, desactualizada, no importa. Todavía es un punto final REST. Entonces, el punto final aún no tiene tipos. Entonces, lo que comenzamos a pensar fue, bueno, si estamos mirando este diagrama del cliente y luego colocamos el motor de GraphQL, digamos que comenzó desde el cliente y luego se movió a la puerta de enlace. ¿Podríamos realmente también simplificar el trabajo de consultar nuestros servicios backend? Tal vez nuestros servicios backend sean... ¿Por qué no podemos disfrutar también de todas estas cosas geniales en el backend? Y algunas personas, lo que hacen es comenzar a usar GraphQL en el backend, lo cual tiene beneficios, pero también tiene desventajas. Y ese es un buen debate para tener, por cierto, como, ¿deberíamos convertir todo en GraphQL o tal vez hay otros protocolos que son mejores? Yo diría, sabes, también podemos... Entonces hay un par de cosas aquí. En primer lugar, depende de tu caso de uso, tal vez, por lo general, esto simplemente no es realista. Como que tienes muchas fuentes de datos existentes. Esas fuentes de datos probablemente estén escritas, depende de tu empresa, pero probablemente escritas por otros equipos. Esos equipos no tienen tiempo para migrar a la última tecnología genial y de moda porque simplemente decidiste que esta es la tecnología genial, nueva y de moda. Por lo general, es irrealista. Pero digamos que es realista, digamos que ahora podemos elegir mover todas nuestras fuentes de datos a GraphQL, ¿deberíamos hacerlo? Y ese es un gran debate. De hecho, ayer estuve en un panel con Lee Byron y planteé esa pregunta y debatimos un poco al respecto. Entonces, una cosa es que, como dije, todas las fuentes de datos existentes que tenemos, puede haber, tal vez no tengan tiempo para migrar a GraphQL y sea irrealista, que es el uso más común. Pero también si podemos, pensemos en el trabajo que vimos en la diapositiva, ¿dónde está? Esta diapositiva. En GraphQL, este es el trabajo que se está haciendo en la caja de GraphQL o básicamente el proveedor. Cuando hablamos de cliente y servidor, digamos que este es el servidor, ¿verdad? Digamos que este es el servidor de GraphQL en este momento. El trabajo de manipular los datos y orquestar los datos, esperar todas las llamadas de red. Todo este trabajo se realiza actualmente por el proveedor. El cliente no necesita hacerlo a través de la red. Eso está bien, pero eso es una compensación. Entendemos la compensación. Lo que obtenemos de la compensación es que a través de la red obtenemos menos datos. Por lo tanto, es más eficiente para las llamadas de red. Y también ahorramos mucho código en el cliente. Pero como dijimos, por todo tipo de razones, podríamos hacer una compensación diferente y hacerlo en el cliente. Ahora, si estamos hablando de comunicación de servicio a servicio, estamos hablando de puerta de enlace a backends, como en este caso. En este caso, generalmente nos importa un poco menos el tamaño de los datos que pasan por la red. Entonces, el hecho de que podamos hacer GraphQL aquí, como en los servidores, eso significa que ahora las fuentes de datos realmente necesitarán hacer más trabajo, ¿verdad? Necesitarán filtrar los datos y hacer todo ese algoritmo que la función de GraphQL está haciendo. Y eso también dificultará el almacenamiento en caché. Tal vez no sea la compensación correcta. No estoy diciendo que no sea nada, solo digo que es, sí, es, solo digo que es una compensación y puedes elegir esto y puedes elegir eso. Entonces, otra opción, por cierto, es gRPC, ¿verdad? gRPC es un protocolo muy eficiente y aún con tipos, como protobufs. Por lo tanto, aún obtenemos algunos de los beneficios de GraphQL, como tipos y SDK generados, pero no obtenemos el lenguaje de consulta. Entonces, el lenguaje de consulta es lo que, como, tiene una compensación y debemos pensar para cada fuente, ¿queremos gRPC o queremos GraphQL? Sí, ese es el debate. También, ayer, tuve una conversación con Lee y habló un poco sobre cómo es, cuál es la configuración en Facebook y ahora en Robinhood, donde trabaja. Y también fue parte de un debate más amplio sobre Federation, porque Facebook, lo que siempre digo es que Facebook, y en este caso también Robinhood, y Facebook es el más grande, es el esquema GraphQL más grande del mundo, no utiliza Federation. ¿Verdad? Entonces, seguimos diciendo que necesitas Federation para escalar tus API de GraphQL, pero en ese caso, ¿por qué Facebook no usa Federation? ¿Verdad? Entonces, tal vez haya, no necesariamente es la solución correcta para escalar, lo que eso signifique. Por eso fue importante para mí compartir con la audiencia, de hecho, lo que está sucediendo en Facebook, y fue bueno que Lee Byron estuviera allí. Entonces, hay todo tipo de compensaciones y tal vez no vamos a convertir todo en GraphQL por todo tipo de razones. Ahora, pero aún queremos obtener algunos de los beneficios de GraphQL. Aún queremos obtener el esquema de tipos y tal vez el lenguaje de consulta. Pero tal vez no queremos cambiar nuestras fuentes de datos tanto porque es irrealista cambiarlas y también porque tal vez no sea arquitectónicamente bueno cambiarlas. Tal vez necesiten ser gRPC, tal vez necesiten ser REST y luego sea más fácil almacenar en caché. Por cierto, también hablaremos sobre el almacenamiento en caché de GraphQL más adelante, pero en general, si tienes resultados predecibles, puede ser más fácil almacenar en caché. Entonces, veamos nuestros backends existentes. Lo que pensamos fue, ¿podemos mirar nuestros backends existentes y generar... Como, obtener la información que obtenemos de todos modos, ¿verdad? Porque sus backends existentes, incluso si no son GraphQL, pueden ser API abierta, por lo que tenemos esquemas o esquema JSON o gRPC. Tal vez no tengan todo esto, pero hay documentación sobre lo que está sucediendo allí.

Como, podemos consultar la documentación, pero la documentación podría decir que este punto final devuelve este JSON, y este punto final devuelve esta estructura. Y tal vez solo tengamos los registros, ¿verdad? Tal vez podamos, tenemos los datos en vivo, o podemos hacer ping. Como, ¿qué hacemos cuando comenzamos a desarrollar una fuente de datos de Apollo? Simplemente llamamos al punto final para obtener cualquier información que obtengamos, intentamos entenderla y luego la llamamos punto a punto, y con suerte entendemos los datos que obtenemos. Entonces, lo que pensamos fue hacer que ese proceso sea más seguro y eficiente. Tal vez tomemos todas esas formas diferentes de entender lo que todas esas fuentes diferentes están dando, y tal vez podamos crear esquemas a partir de ellas. Y si vamos a crear esquemas a partir de ellas, ¿por qué no crear un esquema de GraphQL a partir de ellas? Entonces, podríamos tomar esquemas JSON, Swagger, GRPC, tal vez creemos manualmente un esquema JSON o lo que sea, y tal vez registremos respuestas, y a partir de eso podamos generar esquemas de GraphQL. Saltaré esa parte por un segundo. Eso es GraphQL Mesh, que es una biblioteca que toma todo tipo de fuentes diferentes, sin importar qué fuentes sean. Pueden ser bases de datos SQL, todo tipo de cosas. Y genera esquemas de GraphQL a partir de ellas. Los toma, los convierte y genera artefactos que puedes guardar localmente, como si no quisieras inspeccionar tu backend, tus servicios todo el tiempo, genera artefactos. Esto es, por cierto, un cambio nuevo que se hizo recientemente. Si algunos de ustedes están usando GraphQL Mesh y no han actualizado en los últimos dos o tres meses, este es un cambio nuevo que hemos hecho. Genera artefactos y luego puedes tratar esos artefactos como si fueran puntos finales regulares de GraphQL. Lo mostraré en un segundo. Pero ahora básicamente puedes hacer lo que quieras con esos artefactos, como si fueran excelentes puntos finales. Puedes consultarlos, puedes vincularlos, puedes enviarlos a GraphQL Inspector para verificar si hubo algún cambio que rompiera algo, cualquier cosa así. Sí, eso es GraphQL Mesh. Como puedes ver aquí, cualquier fuente que puedas consultar, trabajamos con muchas diferentes, por eso también nos expandimos a otras tecnologías de API, y comenzamos a ver también ventajas y desventajas allí. Hay muchas cosas geniales. Por ejemplo, en los esquemas JSON, no tenemos GraphQL, así que comenzamos y también en OpenAPI. Entonces, comenzamos a agregar nuevas características a GraphQL. Comenzamos a agregar características a la especificación de GraphQL, que es otro tema del que quiero hablar contigo hoy. Hay mucho de lo que quiero hablar contigo. Pero en otro tema quiero hablar contigo sobre cómo con Envelope, que es el nuevo sistema de complementos de GraphQL que construimos, puedes usar características de GraphQL que no están en la especificación de GraphQL. Entonces, cuando hablamos de qué servidores de GraphQL debes usar, tengo una opinión muy específica al respecto. Espero que podamos llegar a eso pronto. Entonces, nuevamente, GraphQL Mesh y podemos consultar GraphQL, pero utilizando nuestros servicios existentes. Y como dije, no pusimos esa carga, fue la misma idea de ejecutar GraphQL en el cliente. Obtenemos un SDK de GraphQL que ha sido ejecutado por el cliente, o en este caso, el servicio que consulta los servicios. Entonces, digamos que la puerta de enlace de GraphQL obtiene un SDK. Te lo mostraré en un segundo a qué me refiero, tal vez sea confuso, pero básicamente, todo lo que enseñé hasta ahora, si estás usando Apollo, esto es un reemplazo para las fuentes de datos de Apollo. Entonces, usemos el servidor de Apollo. Y luego, cuando llamas a fuentes de datos remotas, usas fuentes de datos de Apollo. Básicamente, esto es una forma mucho más avanzada y mejor de fuentes de datos de Apollo. Entonces, la primera fase que creo que debes hacer si estás usando el servidor de Apollo es cambiar y eliminar tus fuentes de datos de Apollo y migrar tus fuentes de datos de Apollo al SDK de GraphQL Mesh. Eso es una de las primeras cosas que estamos haciendo. Eso es uno de los primeros pasos que estamos dando una vez que las personas ya tienen un servidor de GraphQL en producción. Estamos cambiando las fuentes de datos de Apollo al SDK de GraphQL Mesh. Nuevamente, el esquema, si puedes ver a la derecha, el servidor de GraphQL, digamos en tu caso si estás usando el servidor de Apollo, no ha cambiado. Todavía escribiste un esquema de GraphQL y todavía escribiste resolvers. Pero dentro de estos resolvers, vas a usar los SDK de GraphQL Mesh en lugar de las fuentes de datos de Apollo. Y el SDK de GraphQL Mesh no solo puede tomar cada fuente convertida en GraphQL y darte un SDK completamente tipado, también puede tomar muchas, muchas fuentes de datos diferentes y fusionarlas en un solo SDK de GraphQL. Ahora, eso es interesante porque lo que podríamos hacer con eso es básicamente, digamos que daré un ejemplo de un cliente que tenemos. No voy a mencionar el nombre del cliente, pero es un sitio web de comercio electrónico enorme. Son comercio, en realidad. También tienen comercio y también tienen un sitio web de comercio electrónico enorme, y tienen toneladas, toneladas de servicios diferentes. Para los servicios, usan Java y OpenAPI y cosas así, y luego para la puerta de enlace, están usando TypeScript. Y migraron recientemente de Apollo Server a Envelope, que es algo común con... Hablaré sobre Envelope un poco más adelante. Entonces, lo que hicimos fue comenzar, eso es exactamente lo que comenzamos a hacer allí. Comenzamos con las fuentes de datos de Apollo una por una y las migramos al SDK de GraphQL Mesh. Al final del día, lo que obtuvimos es básicamente un catálogo, una representación de GraphQL de todas las fuentes de datos en esa empresa, es enorme. Es una empresa enorme. Aunque estas fuentes de datos no eran en absoluto GraphQL. Solo eso hizo que básicamente todos los datos en toda la empresa fueran visibles para todos, más consultables y más fáciles de consultar para todos. E incluso la gerencia de repente vio lo que tienes y comenzó a ver duplicados, no solo líneas de código, sino duplicados reales en los equipos. Había equipos que básicamente estaban desarrollando muchas cosas similares. Entonces, la gerencia realmente comenzó a mirar todo el enorme esquema que generamos y comenzó a comprender y gestionar mejor todos estos equipos. Pero nuevamente, esta fue la primera fase, en realidad no hicimos nada con la puerta de enlace y no cambiamos nada más que crear un SDK más agradable para los resolvers. Básicamente, todo lo que queríamos hacer aquí, te mostré todo tipo de soluciones sofisticadas, pero quiero mostrarte nuevamente lo que hicimos aquí. Simplemente tomamos los resolvers que estaban parcialmente tipados y todo lo que hicimos fue hacer que las llamadas remotas fueran tipadas, eso es todo. Pero en el proceso, creamos un catálogo completo de todos los datos que existen en esa empresa. Eso es un poco sobre GraphQL Mesh. GraphQL Mesh es como, nuevamente, es un SDK poderoso que fusiona todo, como la primera fase es tomar cualquier fuente y convertirla en GraphQL. También quiero mostrarte código y ejemplos de cómo se ve realmente. Y también veo si queremos hacerlo, te enviaré un taller que puedes seguir commit por commit. De acuerdo.

Pero luego también fusionamos eso en un solo SDK muy poderoso. Por cierto, eso es fusión. Si ya estamos hablando de eso, esta fusión puede... Es una fusión de muchas fuentes diferentes de GraphQL. GraphQL-mesh admite dos tipos diferentes de capacidades de fusión. Uno es Apollo Federation y el otro es schema-stitching. También tengo mucho de qué hablar sobre estos temas.

Apollo Federation se comercializó como la próxima versión de schema-stitching, pero para ser honesto, es algo diferente y tiene muchos compromisos. También dejaron de mantener schema-stitching y las herramientas de GraphQL. Entonces, lo que hemos hecho es tomar las herramientas de GraphQL de Apollo. Reconstruimos completamente schema-stitching y hoy en día schema-stitching es en realidad una solución más capaz en términos de habilidades que Apollo Federation, porque en Apollo Federation es como una solución muy opinada, que podría ser beneficiosa. Con schema-stitching, en realidad podrías federar servicios de Apollo Federation hoy. Pero también podrías hacer más. Podrías asignar algunas de las responsabilidades también a la puerta de enlace y no solo a los servicios. Entonces, incluso si ahora estás debatiendo contigo mismo a medida que creces en tu escalabilidad, ¿necesito usar Apollo Federation? ¿Necesito usar schema-stitching? ¿O tal vez no necesito ninguno de esos en absoluto? Definitivamente podríamos hablar de eso aquí hoy o también puedes enviarme un mensaje más tarde y hablar conmigo más tarde, porque como acabo de mencionar, hay muchos enfoques diferentes aquí. Y aunque algunas empresas quieren mostrar que la única forma de escalar es Apollo Federation, siempre piensa que Facebook no está usando Apollo Federation. Uber no está usando Apollo Federation. Twitter no está usando Apollo Federation. Y probablemente son de mayor escala que tú. Entonces, hay otras soluciones y debes tener en cuenta todos los compromisos diferentes que obtienes. También una ventaja de schema-stitching es que puedes ver que tiene mecanismos similares a Federation, pero es solo GraphQL. No hay una nueva especificación aquí, los servidores que escribes son solo servidores GraphQL simples y antiguos. No necesitas encerrarte en un cierto ecosistema, en el ecosistema de Apollo en ese caso, o cualquier otra empresa que ahora esté usando, que tenga todo tipo de soluciones de Federación. Sí, esas son solo cosas para recordar.

Entonces, sí, GraphQL mesh, como dije, la primera fase es crearlo como un SDK. Como ves aquí, digamos que tengo un servicio, una puerta de enlace que tiene un esquema GraphQL y cosas así, puedo usar eso como un SDK. Pero también puedo tomar GraphQL mesh y ejecutarlo como un servidor, como un lugar central para ejecutar todo lo que llamo y todo pasa por este lugar, y luego este lugar lo envía a todos los demás servicios. Entonces, puedes pensar en GraphQL mesh como, digamos, como Apollo Federation, pero para cualquier fuente. Puede ser cualquier cosa y no solo servicios federados. Pero lo que sucede con GraphQL mesh, aunque esto es como Apollo Federation, pero para cualquier fuente, no necesariamente pensamos que sea una buena idea. Tal vez no quieras el lugar central por el que todo pasa. Tal vez puedas tener la misma experiencia y obtener todo el gráfico de todas las diferentes fuentes de datos, pero la ejecución estará en los productores. Será descentralizado y distribuido. No hay un único punto de falla. Entonces, la puerta de enlace aquí, cuando llama al servicio, como desarrollador sientes que tienes un solo lugar con toda la información, pero lo que realmente está sucediendo es que las solicitudes de red van directamente a los servicios y no a través de un lugar central como Apollo Federation o como todo tipo de otras soluciones en la comunidad. Entonces, ese es otro compromiso que, a medida que creces y escalas, debes considerar, ¿verdad? Porque si ahora estás creando un lugar central por el que todos y todo pasa, cuanto más grande sea la escala que obtendrás, si este lugar va a, si este lugar, en primer lugar, habrá más carga en este lugar. Y en segundo lugar, si este lugar se cae por cualquier motivo, básicamente has jodido todo. Entonces, tal vez sea mejor que en realidad esté distribuido.

Quería mostrar un poco, para demostrar este enfoque de GraphQL Mesh y todas las cosas que podemos hacer con él. De hecho, creamos un taller que, confirmación por confirmación, te guía a través de esto. Primero que nada, compartiré el enlace. Así también puedes hacerlo realmente cerca contigo mismo a tu propio ritmo y en tu propio tiempo sin estrés. Este es el taller, el taller de GraphQL Mesh. Permíteme compartirlo aquí. Pero de todos modos, estoy escribiendo aquí mi correo electrónico, escribiré mis detalles aquí. Creo que deberías copiarlo porque no sé si guarda todo el historial. Siempre puedes contactarme para cualquier cosa. También mis detalles están en mis perfiles de GitHub. Solo compartiré el mío. De todos modos, ese taller, ves que hay cinco confirmaciones en ese taller. Cada confirmación es una fase de trabajo de lo que acabo de decir. Entonces, la primera fase es probablemente lo que tienes hoy con Apollo Server y Apollo Data Sources. Probablemente el servidor con el que te vas a producción, la mayoría de los usuarios, así es como trabajan. Y luego, básicamente, vamos confirmación por confirmación. Estamos agregando gradualmente una malla. Primero, simplemente reemplazamos las fuentes de datos con el SDK de la malla. Luego, en realidad, hasta que lleguemos al punto en el que, ya sabes, lo llamamos sin código. Básicamente no hay nada afuera, solo las configuraciones gráficas de la malla. Y cada paso aquí es un buen paso. No necesitas llegar hasta el final con tus servidores. Depende de tu arquitectura u otras cosas como esas. Pero sí, déjame solo, ¿ves mi pantalla, verdad? Creo que sí. Entonces, solo te guiaré a través del servidor en lugar de ejecutar todo esto. Este es un servidor regular de Apollo Server. Como ves, instalamos Apollo Server. Tenemos una instancia de Apollo Server aquí. Básicamente tenemos dos APIs aquí. Una es la API de cervecerías.

Y de la otra manera, otra es una API geográfica, todo tipo de ciudades alrededor del mundo. Y también tenemos fuentes de datos de Apollo. La API REST de geografía y la API REST de cervecerías abiertas. Eso probablemente es similar a lo que tienes hoy. Tal vez intente algo. Solo un segundo. De acuerdo, déjame, iré aquí. Solo tengo un lienzo en blanco aquí. Veamos si funciona. Digamos que tenemos, veamos si esto funcionará. Sí. Básicamente lo que tenemos aquí son dos fuentes de datos. Tenemos, esta es una API geográfica y esta es, llamémosla API de cerveza. De acuerdo. Esas son APIs REST y están fuera de nuestro control. Digamos que son microservicios de un equipo diferente o en este caso, es de terceros, ¿verdad? Eso es lo que son. Ahora, lo que estamos construyendo aquí ahora mismo, lo que normalmente hacemos es construir una API de GraphQL. Digamos que este es Apollo Server, y este servidor Apollo Server se encuentra aquí y consulta esto, y luego tenemos, por supuesto, como un cliente aquí, muchos, todo tipo de clientes diferentes aquí que están consultando esto. Están consultando este servidor GraphQL utilizando GraphQL. Sí, entonces, básicamente, esto es GraphQL. Sí, eso está bien, eso es lo que es. Ahora, volvamos a la configuración. Entonces, esto es, y probablemente todo lo que te estoy mostrando aquí es a lo que estás acostumbrado, ¿verdad? Entonces, no estoy instalando las dependencias en este momento porque quiero hacerlo muy rápido. Entonces, tenemos fuentes de datos de Apollo, ¿verdad? Como tal vez lo haga, veamos, solo para que no haya errores. Entonces, tengo una fuente de datos de Apollo, fuente de datos de interés. Le doy, ya sabes, como una URL base, y estoy creando una función Find Breweries API, con el Get de las cervecerías, ¿verdad? Eso es lo que obtengo. Lo mismo para la API geográfica, ¿verdad? Tengo una base, y la llamo aquí. ¿Cuál es el problema aquí, con las fuentes de datos de Apollo? Luego, en los resolvers, quiero llamar a esta fuente de datos, ¿verdad, como lo estoy agregando aquí, ya sabes, si no estás al tanto, así que estoy agregando aquí todas mis fuentes de datos de Apollo, y luego puedo, al contexto, así es como lo pongo en el contexto de mi servidor GraphQL, y luego, puedo traerlo del contexto y llamar a la función. Este es mi resolver. Eso está bien, pero si miramos esto, esto soy YO. Esto no es un tipo en absoluto. No sé qué voy a obtener aquí. Incluso si obtengo GraphQL Code Generator, para generar esos tipos, GraphQL Code Generator, lo que hará, automáticamente escribirá todos los tipos aquí, y también agregará automáticamente un tipo de retorno aquí. Así es como funciona GraphQL Code Generator. Entonces, aunque GraphQL Code Generator básicamente generará las funciones para esta función, cuando llamo a esto, no tengo ningún tipo. De acuerdo. Entonces, nos estamos moviendo. Lo que vamos a hacer es instalar GraphQL Mesh. Voy a cambiar a ese commit. Cuando estés siguiendo el taller, te mostraré ese commit aquí. Así que puedes ir al commit y ver la diferencia. Lo que hemos hecho es instalar npm install GraphQL Mesh CLI, open API y JSON schema. Explicaré por qué en un segundo. Eso es todo lo que hemos hecho. Ahora, déjame también, uno yarn, una vez que estemos aquí. Entonces, lo que hemos hecho es instalar aquí y luego hemos introducido el archivo YAML de GraphQL Mesh. Permíteme mostrarte ese archivo YAML de GraphQL Mesh. El archivo YAML de GraphQL Mesh nos permite y nos permite básicamente definir lo que necesitamos. Como nuestras fuentes. Entonces dijimos que una fuente es geodb, esta es esta API, es la API geográfica. Ahora quiero que... Lo que sucede con esta API, tiene una definición OpenAPI Swagger. Permíteme ir aquí, geodb, creo, no geo, ¿qué es? Mesh, build mesh. De acuerdo, esto es un OpenAPI, tiene un Swagger, permíteme mostrarte. Oh, es bueno que también lo esté imprimiendo, así que te lo mostraré en un segundo, el proceso de lo que ha hecho aquí. Este es un archivo Swagger de esa API que describe todas las cosas diferentes que podríamos consultar desde aquí. Entonces, esa es una API, la otra API es la API de cervecerías abiertas, esta API ni siquiera tiene un Swagger, solo tiene un sitio web con documentación. Ya sabes, piensa que probablemente tienes un equipo y el equipo tiene un sitio web de documentación, en realidad no tienen nada real con lo que trabajar. Todo lo que tienen aquí son ejemplos, ¿verdad? Ves, tienen un punto final y el ejemplo. Lo que he hecho aquí con Mesh, le dije, oye, Mesh, esto es como una cervecería abierta, es una API de esquema JSON, así es como la llamas. Y esas son las cosas que quiero obtener de ella. Es un método llamado Get, este es el camino de las cervecerías, ves, lo obtuve de aquí, cervecerías, quiero generar el campo de consulta. Y aquí está la solicitud de ejemplo y aquí está la respuesta de ejemplo, solo copié eso de aquí. Y luego, solo esto es toda la configuración de GraphQL Mesh, de acuerdo. Básicamente, lo que he hecho, lo que estoy haciendo manualmente de todos modos en mi cabeza, simplemente lo puse aquí. Ahora, cuando ejecuto Mesh Build, lo que sucedió es que puedes ver aquí, espero que puedas verlo lo suficientemente grande, limpiando los artefactos existentes, leyendo la configuración de la malla, generando el esquema de la malla, generando artefactos. Esto lo explicaré en un segundo. Así que veamos qué tenemos ahora aquí. Veamos las fuentes.

Todo esto es generado, dot mesh es generado. Veamos GeoDB. Lo que hizo, llamó a ese punto final que dijimos, y básicamente descargó el esquema Swagger aquí. Así que tenemos todo el esquema Swagger localmente. Así que la próxima vez, si eso es así, digamos que el archivo Swagger no está disponible, todavía lo tenemos localmente aquí.

Y aquí tenemos lo generado, básicamente GraphQL Mesh generó el esquema JSON para nosotros basado en estos ejemplos. Así que eso es genial. Esa es la primera fase. Esas son las fuentes con las que podemos trabajar. Pero luego, lo que GraphQL Mesh hizo, generó esto. Lo que ves aquí es un archivo de esquema GraphQL que se genera según estas fuentes. Así que todo ese archivo de esquema, no escribimos nada aquí. Ves, hay toneladas de países aquí, enumeraciones y cosas así. Todo esto se genera según las fuentes. Así que eso es lo que Mesh hizo por nosotros.

Ahora, volvamos a ese commit que hemos visto. Eso es lo que Mesh hizo. Ahora veamos cómo afectó a nuestro proyecto. En primer lugar, eliminamos por completo el código de la fuente de datos. Se fue. Pero ahora veamos nuestros resolvers. En lugar de tener estas fuentes de datos.godbapi.dat, tenemos el SDK de GraphQL Mesh que cargamos aquí. Y tenemos esto. Encuentra ciudades usando la consulta get. Veámoslo en el código fuente para que sea realmente interesante porque ahora se ve igual, pero simplemente eliminamos la función de la fuente de datos. Pero si miramos aquí, esta es la parte interesante. Permíteme, sí. Veamos aquí. Mira esta función. Esto está completamente tipado. Los argumentos están tipados. En este caso, no están tipados porque la fuente no está tipada, pero aquí ves, está completamente tipado. Y más que eso, ahora puedo hacer esto. Puedes ver que tengo todas las diferentes funciones que esta API tiene con autocompletado que esta API me brinda. Si voy a llamar algo aleatorio, no es verdadero, no se va a compilar. Así que tengo esta increíble seguridad de tipos que se genera para mí. Así que eso es por qué esto es mucho mejor que la fuente de datos de Apollo, pero eso es solo la primera fase de usar GraphQL Mesh.

Veamos eso. Ese es solo un paso del commit del tutorial. El siguiente paso es que incluso podemos llevar esto más lejos. Oh, déjame ver lo que tenemos, este es el SDK. No expliqué la otra parte aquí, este es el SDK. Solo le dije a Mesh que generara el SDK. Eso es lo que le dije a Mesh aquí. Por favor, a partir de todas estas cosas, dame un SDK. Eso es lo que Mesh ha hecho. Por cierto, Mesh generó ese SDK utilizando GraphQL Code Generator en el fondo. Así que Mesh en sí mismo se divide en muchas pequeñas bibliotecas. Luego pasemos a la siguiente fase. Permíteme revisar el otro, el siguiente. Veamos. Lo que estamos haciendo en la siguiente fase es ver el archivo mesh RC, en lugar de generar un SDK, le dijimos a Mesh, en primer lugar, fusionamos esas diferentes fuentes. Así que aquí podemos decirle a Mesh lo que hacemos aquí. En realidad, podemos tener todo tipo de código personalizado. Digamos que queremos agregar resolvers personalizados a eso. Podemos hacer que Mesh lo ponga aquí en el archivo de configuración. Así que simplemente ponemos aquí el SDL extendido que queríamos porque queremos conectar realmente esas dos fuentes juntas. Así que lo extendimos aquí y luego el resolver en sí es solo un archivo. Y ese archivo está completamente tipado, por cierto, porque todo está completamente tipado y esa es la conexión entre las cervecerías y el mesh. Tal vez lo explique mejor. Permíteme ejecutarlo. Tal vez sea más fácil.

Lo que ves aquí es una consulta. Estoy consultando la búsqueda de ciudades usando GATS, así que estoy consultando una fuente, pero luego también estoy consultando las cervecerías dentro de esa ciudad, como si fuera una sola fuente, pero son dos fuentes diferentes. Esa conexión podría hacerse en código, pero en este caso, en realidad lo hice aquí en las configuraciones de Mesh. Además, por cierto, no tenemos una forma más fácil de definir eso. Y con el resolver personalizado, no sé por qué está así. Creo que es solo, de todos modos, pero esto es, sí. Así que creo que simplemente hizo una actualización a VS code. Esa es la siguiente fase. Como lo que hemos hecho aquí, volvamos a ver la definición de eso. ¿Qué hemos eliminado? Hemos eliminado los resolvers y hemos eliminado por completo las definiciones de tipos. Quiero decir, incluso el índice, ¿verdad? Todo esto lo hemos eliminado. No nos quedó mucho, ¿verdad? Hemos eliminado por completo el servidor Apollo. Ahora Mesh actúa como nuestro servidor. Así es, eso es todo lo que tenemos. Piensa en el proyecto anterior, teníamos toneladas de código y toneladas de cosas. Ahora todo está generado y todo lo que tenemos es esta función adicional de resolvers. Pero luego vayamos un paso más allá. Sin código. Podemos hacer esta conexión directamente desde aquí, desde la configuración. Como la conexión entre dos fuentes, básicamente podemos decir, desde el objetivo, ¿de dónde lo obtenemos? ¿Cuál es el conjunto de selección? Y desde la fuente, ¿de dónde lo obtenemos? ¿Y cómo los conectamos? Por cierto, hay una API aún más fácil. Y ahora que estamos haciendo esto, permíteme revisar esto. Estoy saltando aquí, como esto es una masterclass, que suelo hacer para, pero veamos. ¿Cómo obtengo, veamos master. Sí, solo cambia a bench. De acuerdo, así que ahora si miramos esto, no tenemos código aquí, solo tenemos un archivo package JSON. Un archivo meshRc y los recursos de ejemplo, fuentes de ejemplo. Eso es todo. Solo el meshRc es todo lo que necesitamos, y también podemos, ahora es un servidor, así que podemos decirle en qué puerto ejecutarse. Esto simplemente muestra lo flexible que es Mesh, y la introducción gradual, ya sabes, cómo se puede introducir en tu entorno.

Entonces, sí, esto es como, así que compartí el enlace de la masterclass. Guárdalo. Antes de entrar en muchas más cosas que quiero hacer, y ya llevamos 40 minutos, ¿preguntas al respecto? Estoy seguro de que tienes preguntas, así que. Tengo una. De acuerdo. Permíteme hacerlo de esta manera. En mi empresa, trabajé para Zillow en los Estados Unidos. En el proyecto en el que estoy trabajando, tenemos muchos puntos finales. Sabes, cada punto final es como una función, ¿verdad? Sabes, como encontrar esto o obtener eso. Así que lo que hice es que usé code chain, y creé un resolver a mano para cada uno de ellos, sabes, una función para cada uno de ellos. Así que ahora tengo 10 APIs REST y luego funciones. ¿De acuerdo? Entonces, lo que estás usando GraphQL Mesh, lo que estás diciendo en lugar de hacer manualmente la creación del esquema de GraphQL, hacer todo el tipado, hacer todo, ya sabes, el código en ejecución. ¿Puedo usar GraphQL Mesh? Sí, así que aquí viene, déjame tal vez compartir la pantalla. Es una gran pregunta. Así que, en primer lugar, esto es genial lo que has hecho y el código que has hecho, lo que estamos usando aquí en GraphQL Mesh, perdón por el ruido, por cierto. Hay tormentas locas aquí y no es realmente regular. Espero que aún puedas escucharme bien. De todos modos, ¿qué ves aquí? Espera, déjame. Sí. Básicamente tomamos estas fuentes, como esas y generaste algunos resolvers y funciones a partir de ellas. Esto es lo que hace GraphQL Mesh y GraphQL Code Generator. Así que podrías mirar nuestra solución y tal vez reutilizar algo de código y cosas así. Ahora, la pregunta es, ¿todavía necesitamos esto, el esquema personalizado creado aquí? Ahora esta es la pregunta que depende de muchas cosas. Depende de qué, como, ¿es el esquema que esos dos servicios están exponiendo? ¿Es lo suficientemente bueno? Porque a veces en muchas empresas, los esquemas que estas APIs están exponiendo no son tan buenos. Incluso si los conviertes directamente en GraphQL, no es exactamente lo que el cliente pediría. Entonces, en este caso, tendrías un esquema personalizado aquí, pero como hicimos en el paso intermedio, como en el paso intermedio aquí, aún tendrías un servidor y un gráfico, aún tendrías, déjame verificar esto, como aún tendrías definiciones de tipos, ¿verdad? Como aún tendrías las definiciones de tipos aquí porque esas definiciones de tipos serán diferentes. El cliente querría aquí definiciones de tipos diferentes a las definiciones de tipos generadas que Mesh está construyendo, pero tal vez los pasos de tipo que se generan son exactamente lo que el cliente necesita y entonces no lo necesitas en absoluto. En cualquier caso, Mesh te está ayudando porque, y tal vez sea solo partes de él, ¿verdad? Como tal vez algunos servicios son exactamente como quieres y algunos servicios no lo son, tal vez algunos servicios te dan como enormes enumeraciones de 200 valores y no quieres crearlos tú mismo. Así que solo quieres generarlos automáticamente y luego agregar esos esquemas personalizados. Todo eso es posible, pero al menos aquí podrías mirar todas tus diferentes fuentes y usar toda la información que tienes sobre ellas. Así que es una buena pregunta, la respuesta es que depende en su mayoría de tu caso de uso y por eso construimos GraphQL Mesh para ser muy flexible. Entonces, en todos esos casos diferentes, podría ayudarte. En mi caso, funcionará muy bien porque son pequeñas APIs REST creadas solo para el proyecto así que puedo hacer uno a uno y solo el intermedio. De acuerdo, genial. Podrías generar este GraphQL, mostrarlo al cliente, luego el cliente dará su opinión, el cliente podría decir, oh, quiero este campo, quiero que se renombre o algo o no sé qué. Luego podrías ir y cambiar esto y regenerar y obtendrías una nueva API de GraphQL. Exactamente, así que eso es realmente, realmente genial. Por cierto, en ese contexto, ¿por qué son originalmente una API REST en general? Son APIs REST porque tienen un enorme backend, un backend de Java, así que es como, todo proviene de eso. En Zillow, tienen millones de inventarios y cosas así. Así que no podemos acceder directamente con GraphQL. Solo estamos tomando esa porción, esos servicios y luego usándolos, sí. De acuerdo, sí, entonces eso suena como un caso de uso perfecto para GraphQL Mesh, ¿sabes? También escribí mis detalles. Luego incluso puedes mostrar esquemas y puedes preguntarme qué pienso al respecto. Pero realmente esto es por qué creamos GraphQL Mesh. Exactamente este tipo de razones. De acuerdo, entonces, de nuevo, tal vez aquí, ya sabes, teóricamente esto podría convertirse en una puerta de enlace de GraphQL Mesh. Por cierto, esto es, entregamos GraphQL Mesh como una imagen de Docker, así que podrías simplemente tomar, básicamente tomas una imagen de Docker, si lo estás usando en este contexto, puedes simplemente tomar una imagen de Docker, enviar la imagen de Docker, la configuración de GraphQL Mesh, y eso es todo, obtienes un servidor. Déjame, alguien de la comunidad lo hizo, pero luego comenzamos a publicarlo nosotros mismos. Pero solo, creo que el tipo que lo creó hizo una ilustración genial. Sí, esto. Entonces, básicamente, solo obtienes el Docker con el SDK de GraphQL Mesh, y ahora tienes una puerta de enlace automática de GraphQL para todas tus diferentes fuentes sin código, básicamente. Así que es solo, nuevamente, podría ser con código y podría ser personalizado, por lo que este es solo un ejemplo de cómo podrías hacer esto. De acuerdo, eso es la puerta de enlace de GraphQL Mesh. Ahora volvamos a, digamos que tenemos un servidor de Apollo aquí y digamos que usamos GraphQL Mesh como un SDK, ¿verdad? Entonces tenemos algo así. Este es el SDK de GraphQL Mesh que llama a nuestras diferentes fuentes como sí, este es nuestro SDK de Meshes y esto es genial. Ahora el siguiente tema del que quiero hablar es Envelope. Así que déjame ver, no sé si pasaré por todas las diapositivas, no es realmente necesario, pero pasaré por algunas de las cosas que podemos hacer. Entonces, ¿qué queremos de un servidor de GraphQL? Digamos ahora nuevamente, nuestras fuentes de datos, tenemos un servidor de Apollo. ¿Qué queremos realmente de Apollo server, o simplemente de un servidor en general? Porque GraphQL JS es el que hace toda la ejecución y todas estas cosas. Entonces, ¿qué queremos de un servidor? En mi opinión, lo que queremos de un servidor es la creación de un esquema. Podría ser con GraphQL tools, podría ser con el enfoque de código primero, lo que queramos. Queremos que maneje la comunicación por nosotros, ¿verdad? Como tal vez sea HTTP, tal vez si estamos usando tiempo real, como web sockets, SSP, cosas así. Y tal vez realmente queremos implementarlo en el borde, como entornos sin servidor como funciones de Azure, AWS Lambda, e incluso en el borde, como trabajadores de CloudFlare, que es algo que la gente olvida que es realmente, realmente genial, en realidad, para implementar tus servidores de GraphQL allí. Y, por supuesto, queremos almacenamiento en caché, monitoreo, trazado, registro, seguridad y manejo de errores, todas las cosas que queremos que nuestros servidores hagan. Y queremos todo un ecosistema de estas cosas, ¿verdad? Queremos todas las, porque todos tienen sus propias soluciones diferentes. Ahora esta es una diapositiva muy opinada. Sí, esta es mi opinión. Pero en mi opinión, los marcos actuales, incluido Apollo Server, son muy opinados y no están muy bien mantenidos.

Pero lo que sucede es que esas opciones, en primer lugar cuando te adentras en configuraciones más complejas, esas opciones son limitadas. Y lo segundo es que no solo son limitadas, si no están actualizadas, manteniendo todo actualizado, entonces estamos atrapados con dependencias actualizadas y no podemos actualizarlas nosotros mismos. También suelen envolver, los marcos actuales envuelven todas las tuberías de solicitud. Entonces eso significa que se vuelve mucho más difícil, necesitamos diferentes, como todo tipo de parches y todo tipo de paquetes diferentes de npm si queremos implementar en diferentes entornos que no sean de nodo regular. Si queremos usar Festify, necesitamos algo más. Si queremos usar Core, queremos algo más. Si necesitamos implementar AWS Lambda, necesitamos algo más. Si queremos implementar en los trabajadores de Cloudflare, no estoy seguro si es posible. Y se vuelve muy difícil, algunas personas lo mencionaron. Y es muy difícil de personalizar. Y otra cosa, por cierto, es solo mi opinión, no es solo, no sé. Quiero decir, creo que no es por error. Quiero decir, al final del día, estos marcos tienen un objetivo para que uses los productos de la empresa. Entonces eso significa que la flexibilidad no está en su interés.

Entonces lo que hemos hecho, y nos encontramos con esto mucho porque en The Guild gradualmente, construimos soluciones para las necesidades de nuestros clientes y gradualmente construimos más y más soluciones que no comenzaron desde la construcción de todo el ecosistema. Comenzamos desde cosas muy simples, pero cada vez faltaban más cosas. Y hace un poco más de un año llegamos al punto en el que el marco actual, los marcos de servidor simplemente no eran suficientes para nosotros. Intentamos contribuir estas ideas a, por cierto, Apollo Server y otros, y simplemente, no estaban allí, no eran lo suficientemente flexibles y no fusionaron las PR. Entonces lo que hemos hecho es ir al tablero y decir, tal vez veamos lo que GraphQLJS nos está dando, básicamente nos está dando un par de funciones, analizar, validar, ejecutar y suscribir. Esas son las funciones principales de GraphQLJS. ¿Qué tal si pudiéramos enganchar, construir aros antes y después de cada una de estas fases? Entonces podrías personalizarlo completamente con complementos, pero aún así expondríamos la misma API externamente. Entonces todo seguiría funcionando, y aún puedes hacer todo lo que has hecho antes, pero ahora tienes un sistema de complementos muy poderoso que podría cambiar cualquier cosa. Cosas que hasta hoy no eran posibles, incluso en GraphQLJS no sería posible. Y puedes usar cualquier esquema, puedes usar herramientas de GraphQL, puedes usar geográficos y cualquier otra cosa. Y lo más importante es que, toda la tubería de solicitud está completamente fuera de esta cosa. Recuerda las primeras diapositivas que te mostré, lo que realmente hace GraphQLJS, es solo una función. Esa función no le importa dónde la ejecutes, y no le importa qué tipo de protocolo de comunicación tengas. Entonces, ¿por qué necesitas que todo esté envuelto en una sola cosa? Maneja el HTTP con los marcos que son los mejores en el manejo de HTTP, como Festify, Koa y Express. Luego, tal vez, ya sabes, si vas a entornos de servicio, usa las herramientas que recomendaron que funcionan para ellos, y luego ejecuta GraphQL. ¿Por qué necesitas que todas estas cosas se fusionen? Entonces eso es Envelope. Envelope es el sistema de complementos para GraphQL. Y es realmente genial, porque lo que puedes ver aquí es que con cuatro líneas de código como usuario, acabo de crear un servidor muy extremadamente poderoso. Use schema es solo, estoy trayendo el esquema. Pero luego el análisis, el análisis de consultas, agregué una caché de análisis. Me enganché en el análisis de, este complemento es sofisticado internamente, pero no necesitaste escribirlo. Este complemento se engancha en la fase de análisis de GraphQL.js y luego lo almacena en caché para cada consulta. Lo mismo hace para la validación, sabes, validé una consulta una vez, ¿por qué necesito validarla una y otra vez? Y utiliza un JIT de GraphQL. Si no sabes qué es JIT de GraphQL, es una forma más eficiente de ejecutar y GraphQL, solo te mostraré la biblioteca. Está creado por Zelando. Tienen benchmarks allí que muestran cuán más rápido es esto en comparación con GraphQL.js. Sí, esto es GraphQL.js, como dije, comenzando en prospección, veamos algunos resolutores, muchos resolutores. Sí, ves como este GraphQL.js, hizo 16,000 operaciones por segundo, GraphQLjit, 178, ¿de acuerdo? Entonces, con Envelope, no necesitas saber todos estos trucos y cosas, solo necesitas instalar el complemento y eso es todo. Y con esos cuatro complementos, obtienes un servidor GraphQL completo y extremadamente eficiente, así de simple. Y, pero cuando quieres recrear un complemento, obtienes una API muy poderosa para hacer lo que quieras. Y creamos un centro de complementos, donde puedes explorar complementos para todo lo que necesitas. Como, ya sabes, vamos a Envelope. Si vas al sitio web de The Guild, también lo pondré en el chat, no sé, tal vez ya lo puse. Entonces, voy al sitio web de The Guild, miro aquí todas las diferentes herramientas, y hago clic en Envelope. Así es el sitio web de Envelope. Lo revisaré en un segundo. Explica todo lo que acabo de decir. Pero hay un centro de complementos. Y aquí, ya sabes, lo que puedes ver aquí, puedes ver complementos para trazado, ¿verdad? Entonces, si usas Sentry, o Opent Elementary, o, ya sabes, New Relic, lo que quieras, puedes simplemente enganchar, porque nos estamos enganchando en, es una línea de código, porque nos estamos enganchando en la fase de ejecución real de GraphQL. Entonces, el trazado que obtienes aquí es extremadamente poderoso. Ya sabes, incluso Datadog, y el trazado de Apollo también. Como, parte de las cosas con las que nos llevamos bien en Prometheus, nos llevamos bien con todo. Entonces, podrías usar Apollo Server, incluso, y usar esto. Creo que debería usar Envelope, pero, ya sabes, podrías usar Apollo Studio, por ejemplo, y aún así funcionaría. Por cierto, Envelope también puede ser la puerta de enlace para Apollo Federation, porque con la cosa de usar esquema, déjame mostrarte aquí, hagamos Federation. Ves, puedes usar Apollo Federation, para que puedas obtener, Apollo, por lo general, cuando las personas usan Apollo Federation, usan Apollo Gateway. Pero, con Envelope, en realidad podríamos usar eso, y ejecutar eso en su lugar. No solo usamos Apollo Federation, sino que también podríamos usar todos los diferentes complementos de todo el ecosistema. Es una mejor manera, en realidad, en mi opinión, de usar Apollo Federation, si lo estás usando. Hay más cosas, por supuesto, aquí, como cosas de seguridad de las que hablaremos pronto, autenticación, autorización, todo tipo de cosas así. Sí, y por supuesto, almacenamiento en caché, que es, ¿alguien aquí ha oído hablar de Graph CDN? Sí, no puedo ver lo que la gente está diciendo. Sí, escuché a Max Toiber. Sí. Entonces es realmente genial, ¿verdad? Como él dice, oh, puedes almacenar en caché en todo y todo eso. No quiero arruinar la fiesta, pero si solo lees este artículo, obtienes todo lo que Graph CDN te ofrece, pero de código abierto, solo para que lo sepas. Como todo.

Y esto es porque la gente simplemente no está al tanto de ello porque es bastante nuevo, pero obtienes toda la flexibilidad y todo el poder y puedes implementarlo en el borde. Básicamente, todas las cosas elegantes que están haciendo, puedes usarlas con solo un par de complementos, caché de respuesta y todas las configuraciones que tienes en su interfaz de usuario, puedes ponerlas aquí y listo. Y puedes implementar la caché donde quieras y controlarla, sí, solo para que lo sepas. Así es de poderoso cuando te conectas al sistema. Algo más interesante, interesado en eso. Sí, hay todo un ecosistema de complementos, y lo genial es que puedes usar todos estos complementos sin importar dónde los implementes. No es como si necesitaras una biblioteca diferente o necesitaras un código diferente si quieres implementar ahora en AWS Lambda o en los trabajadores de Cloudflare. Es lo mismo. Está basado, por cierto, no solo en Envelope sino en GraphQL Helix. Es otra parte importante del código aquí en GraphQL Helix, que es, GraphQL Helix es básicamente un servidor que te mostraré un ejemplo llamado, veamos, tenemos 20 minutos. Veamos cuánto puedo hacer en 20 minutos, solo un segundo. Terminaré rápidamente las diapositivas y espero entrar en el código. Entonces, Envelope también es un marco de marcos, ¿verdad? Entonces, la idea no es solo que puedas usarlo tú mismo, sino que también hay otros marcos que realmente lo están utilizando. Como, no sé si has oído hablar de redwoodjs, pero redwoodjs es básicamente, es un marco que se ha construido, que fue construido por uno de los fundadores de GitHub. Es realmente genial, deberías echarle un vistazo. Es como marcos de alto nivel. Entonces hace cosas como, ya sabes, el front-end y el back-end y maneja muchas cosas por ti. Entonces, lo genial allí es que solían envolver Apollo server y Apollo client. Y luego, cuando comenzaron a trabajar con nosotros, básicamente les dieron a los usuarios durante un tiempo la opción de usar Apollo server en el fondo o Envelope en el fondo. Básicamente, un mes y medio después de que dieron esa opción, todos cambiaron a Envelope, entonces redwoodjs eliminó por completo Apollo server y desde hace un par de meses, y por cierto, la charla de su chico que comenzó GitHub también estará en GraphQL Galaxy. Ahora redwood1 está utilizando solo Envelope, eliminaron por completo Apollo server. Y escribieron un artículo al respecto, así que creo que también deberías leer por qué lo hicieron. Por eso digo marco de marcos. Y también creamos PR para loopback para NIST-JS para analizar para todo tipo de otros marcos que están envueltos en GraphQL. Eso es parte de ello. Otra cosa que hemos hecho porque trabajamos con muchas compañías diferentes es que algunas compañías, tienen muchos servidores GraphQL pero quieren compartir las mismas configuraciones como el mismo registro, el mismo seguimiento, las mismas configuraciones de seguridad. Entonces creamos como un sobre de sobres, puedes crear como un conjunto preestablecido de Envelope y luego un servidor solo puede importar eso y luego personalizar su propia cosa. Entonces tienes un conjunto de cómo construyes un servidor GraphQL dentro de tu empresa y luego cada equipo puede personalizarlo. Un ejemplo es Klarna, Klarna es un cliente nuestro y básicamente cambiaron a Envelope desde Apollo y ahora todos sus servidores tienen un conjunto preestablecido de cómo hacen las cosas. Y tienen muchos, muchos equipos diferentes que construyen muchos, muchos servidores GraphQL. La última cosa que es realmente genial de la que solo quiero hablar y también he preparado, como ejemplos llamados para eso, pero veamos cuánto puedo hacer es en realidad como un Babel para GraphQL. Entonces, si recordaras Babel del ecosistema de JavaScript, hay todo tipo de características que el navegador no estaba listo para ejecutar, como todo tipo de nuevas características en JavaScript. Entonces Babel básicamente te dio las opciones de usar estas características incluso si los navegadores no las admiten. Con Envelope, porque nos estamos conectando al sistema, en realidad podemos hacer lo mismo. Entonces, con Envelope, puedes usar defer y stream, puedes usar consultas en vivo, puedes usar one-off, que es realmente genial. No sé si has oído hablar de one-off. One-off es básicamente, es algo que realmente proviene de JSON schema. Puedes, digamos si es un campo de entrada, puedes decir, podría ser una de estas opciones. Y esto es algo que hace, es muy conveniente declarar un esquema de esa manera, y hace muy buenas validaciones. Pero GraphQL todavía está en el proceso de agregarlo realmente a la especificación. Va a llevar mucho tiempo. Con Envelope, puedes usarlo hoy. Entonces, eso es realmente genial. Permíteme, no tengo mucho más tiempo. Así que, solo revisaré rápidamente el sitio web, pero creo que es importante. Entonces, aquí hay introducciones sobre cómo hacerlo y cómo trabajar con él, compartir Envelopes de lo que dije. Estas son todas cosas geniales, pero las guías aquí son la parte importante. En primer lugar, entregamos una guía aquí de todo lo que querías hablar como en torno a la autenticación y autorización, no filtrar información confidencial en producción y proteger contra consultas maliciosas. Persistimos las consultas, limitación de profundidad y limitación de velocidad. Todas estas cosas hasta hoy tenías que ir a talleres y había muchas charlas geniales advirtiéndote que GraphQL es peligroso y necesitas usar nuestra solución especial para esto o aquello. Ahora, todo es muy simple. Hay un artículo aquí que explica todo eso. También he creado ejemplos de código, pero puedes revisar eso más tarde. Y puedes realmente... Ves que es solo cuestión de configurar algunos complementos para hacer que tu servidor sea seguro, como los complementos de enmascaramiento de errores. Entonces, automáticamente enmascarará todos los errores de tu servidor para que no filtres información o deshabilitar el complemento de perspectiva. Todas estas cosas son tan fáciles como eso. Y luego quieres protegerte de consultas maliciosas de GraphQL. Como puedes hacer todas estas cosas. Entonces, podrías usar operaciones persistentes y tenemos un complemento para eso. Y puedes elegir cualquier almacenamiento que quieras para hacer eso. Y podrías limitar las consultas. Es solo un complemento. Limitación de velocidad. Es solo un complemento. Entonces, todas estas cosas solían ser muy difíciles y hay tantos artículos en la web que intentan advertirte sobre ejecutar GraphQL en producción. Y la razón por la que escribieron estos artículos y no te dieron las mejores soluciones es porque generalmente quieren que uses alguna solución que quieren venderte o algo así. Desafortunadamente, la mayoría del contenido en línea está siendo escrito por personas a las que puedes llamar defensores de desarrolladores. Son personas muy agradables, pero yo era uno. Solía ser uno.

Pero lo que olvidas es que están trabajando para una empresa, están abogando por una solución específica que comprarías. Entonces, dar la solución más simple no siempre es en su propio beneficio a veces. Esa es una guía que tenemos aquí.

Otra cosa es, como la autenticación, no debemos nada y lo fácil que es usarlo en esta configuración. Monitoreo y seguimiento, que es algo extremadamente importante cuando entras en producción. Entonces, nuevamente, aquí puedes ver lo fácil que es básicamente conectarte a Sentry. Y lo mismo ocurre con solo una línea de código. Y luego, por supuesto, puedes personalizar las configuraciones y todo, pero puedes ver que aquí tienes básicamente cualquier cosa que uses para la telemetría, cualquier protocolo, cualquier cosa, simplemente funciona.

Esto es sobre características del futuro, ¿verdad? Como mencioné todo tipo de cosas. Puedes ver aquí las RFC, como las RFC abiertas para cada una de ellas. Y llevará un tiempo. Sí, como tienes aquí y aquí y aquí hay todo tipo de RFC. Ya puedes usar esto con Envelop. Así que eso es realmente genial. Y sí, puedes ver aquí el ejemplo de one-off. Los argumentos de fragmento es algo realmente genial que Facebook ha estado usando durante un tiempo, pero aún está en proceso de especificación. Entonces, si quieres usarlo fuera de Facebook, puedes usar Envelop. Algunas personas mencionaron cosas como el cargador de datos, problemas de almacenamiento en caché y suscripciones. Así que escribimos un poco al respecto aquí. En realidad, podemos usar esto con Envelop, pero lo más importante aquí es que esto es básicamente gráficos al final en un artículo. Así que te recomendaría mucho que lo leas porque no necesitas un servicio para construir mecanismos de almacenamiento en caché muy poderosos para GraphQL. Este es en realidad un artículo largo porque queríamos dar mucho contexto y queríamos que las personas realmente comprendieran lo que está sucediendo debajo del capó, pero al final, la solución es realmente simple. Sí.

En cuanto al código, hay muchas cosas que quería mostrarte. Y nuevamente, hay mucho más. Entonces, si vas a nuestro sitio web y revisas todo esto, hay razones por las que creamos cada una de estas bibliotecas. Así que deberías revisarlo. Así que hagamos esto. Demostré. Otra cosa, recientemente editamos un tutorial aquí, un tutorial básico, porque pensamos que los tutoriales básicos son realmente malos. Así que creamos uno nuevo llamado no Typescript Helix. Este es un tutorial según cómo vemos las cosas y cómo todo debería estar separado. Entonces, si realmente quieres comenzar desde GraphQL, pero de una buena manera en mi opinión, en nuestra opinión, deberías consultar este tutorial. Y esto es algo nuevo y vamos a mejorarlo. Así que si tienes preguntas al respecto y todo, avísanos. Y ahora estamos en el proceso de construir uno avanzado. Permíteme obtener el enlace del avanzado. Así que ya puedes usar eso para incluir todas las cosas que quería mostrarte hoy. En realidad, lo que quería mostrarte hoy eran ejemplos de código de todo esto. Así que también puedes leerlo aquí. Todo lo que queremos hablar, pero sí, explora ese repositorio. Este es un tutorial más avanzado. Y con suerte, esto también se incluirá en cómo GraphQL pronto. ¿Qué quería decir? Sí. GraphQL Mesh. Te mostré algunas cosas, pero puedes ver aquí, hay muchos ejemplos diferentes de cómo inventar los ejemplos en vivo. Como puedes jugar realmente con eso. Como, oh, si tienes una API abierta, incluso puedes ejecutarlo en Next.js en el cliente. Como hay todo tipo de ejemplos aquí. Entonces, incluso en Next.js, puedes ver los usuarios, también hay ejemplos aquí, todo el flujo de datos y incluso una parte de federación. Y todas esas cosas, todos estos ejemplos también existen básicamente aquí en los ejemplos, carpetas y muchos más. Así que puedes revisar todo tipo de ejemplos aquí, pero quería mostrarte más cosas en realidad. De acuerdo. Espera un segundo. ¿Puedo detener este ejemplo? Y déjame solo... Terminaré con el último ejemplo, aunque tengo muchos. Veamos. Ah, okay. Entonces aquí escribí, básicamente quería mostrarte una demostración de Envelop con todo tipo de cosas, pero no lo lograremos. Así que solo pondré el enlace aquí. Di una charla al respecto donde en realidad hago, en realidad estoy pasando por el código. En realidad estoy construyendo el servidor desde cero. Permíteme compartirte esto. Entonces puedes ver aquí, estoy dando como un contexto, un poco de lo que compartí antes. Pero desde básicamente aquí, estoy comenzando desde cero. No tengo nada aquí, solo un servidor vacío. Espera. Tengo un servidor vacío y simplemente construyo todo el servidor desde cero, incluido el seguimiento con Sentry en ese caso. Y estoy demostrando como auth zero, como auth zero y también estoy demostrando como consultas en vivo y todo tipo de cosas realmente geniales. Así que todo esto, solo lo compartiré contigo aquí.

Entonces, también puedes revisar y nuevamente, copiar eso. Avísame si puedes copiar todo esto del chat porque no quiero que se pierda, así que guárdalo. Así que esa es otra demostración que quería mostrarte aquí.

Creo que el código aquí está en, déjame ver, así puedes jugar con el código, aquí, sí. Esta es la PR para, aquí puedes encontrar como, oh no, esto no es realmente esto, lo siento. Debería, espera, creo que es solo un segundo. Creo que el código realmente debería ser, me corregiré. Aquí, este. De acuerdo, también lo compartiré contigo. Este es ese código. Nuevamente, quería guiarte aquí, pero nuevamente, puedes ir al video. También compartiré aquí esto, que es lo último que quería mostrarte.

El bleeding edge de Graph Guild. Permíteme ir. Sigamos adelante. De acuerdo, esto es el bleeding edge, básicamente es un ejemplo de todas las nuevas características geniales que puedes hacer con Graph Guild de las que otras personas no están hablando contigo porque sus frameworks no las admiten, pero aquí todo está admitido. Así que esto es como, lo revisaré rápidamente. Esto es solo una consulta regular. Obtengo una cosa, obtengo un formulario, obtengo una respuesta, eso es genial. Aquí hay una mutación, aquí hay una suscripción. Así que puedo suscribirme a contar, prueba de suscripción, ¿verdad? Entonces, cada vez que algo sucede, obtengo algo suscribiéndome a contar, esto es genial. Pero hay cosas aquí que tus consultas regulares y también las suscripciones de repente se volvieron muy difíciles con un servidor de Apollo. Dejaron de admitirlo por alguna razón, aquí podrías usarlo, Y no solo eso, podrías usarlo con web sockets o también a través de HTTP con SSE. Esto es a veces mejor si, por ejemplo, algunos de tus clientes están trabajando en entornos que no admiten web sockets, pero aún necesitas comunicación en tiempo real y a través de socket IO. Todo está demostrado aquí. Pero esto es lo genial. Mira lo que está sucediendo aquí. Estamos enviando una consulta con nombre y campo diferido. El nombre es realmente rápido. Obtengo el nombre muy rápido, pero este campo tarda mucho tiempo. Si lo enviaras como una consulta regular, permíteme eliminar esto. Veamos qué sucede. Estoy esperando mucho tiempo. Y luego, cuando el último campo está listo, obtendré todo. Pero sé que en la interfaz de usuario, está bien que lo obtenga más tarde. Y en realidad quiero que esto se represente rápidamente. Entonces, lo que puedo hacer, puedo agregar las anotaciones defer en esto. Y luego, cuando envío esto, inmediatamente obtengo el nombre de vuelta. Y luego, más adelante, obtengo, cuando está listo, obtengo esto. Esta capacidad es extremadamente poderosa para tus servidores de GraphQL, esta capacidad. Así que esa es una característica. Lamento ir muy rápido, pero también hay Consultas en Vivo. Las suscripciones son una cosa. Pero las Consultas en Vivo son realmente, si no te importa por qué se actualiza data, pero solo quieres mostrar constantemente los datos más actualizados, puedes usar Consultas en Vivo. Sí, solo puedo poner Consulta en Vivo en los saludos y se actualiza constantemente con la información más reciente. Entonces, si estás poniendo, no sé, el precio de algo que está cambiando constantemente o no sé. Hay muchos casos de uso para ello. O, ya sabes, en un chat, si alguien está presente o no, como si está en línea o no, todas estas cosas, las Consultas en Vivo son una característica extremadamente poderosa.