Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga

El Guild es el grupo de código abierto más grande en el ecosistema de GraphQL. Desarrollamos muchas bibliotecas que encajan en una gran visión. Pero la idea es que cada biblioteca es individual. Algunos ejemplos son GraphQL Code Generator, GraphQL Tools y Sceva Stitching, GraphQL para básicamente tomar cualquier fuente como OpenAPI, Swagger, gRPC, SQL y generar APIs de GraphQL a partir de ellas. GraphQL Inspector para prevenir cambios que rompan, GraphQL Modules para distribuir el trabajo entre muchos equipos diferentes en la empresa, y muchos, muchos otros. Y la filosofía del Guild es que cada una de estas herramientas debe y se desarrolla de manera completamente independiente. No necesitas usar las otras herramientas para usar cualquiera de las herramientas aquí. Se ajustan a una gran plataforma, desde la base de datos y las fuentes de datos hasta el front-end. Pero no estás bloqueado a un proveedor. Puedes introducir gradualmente estas herramientas cuando realmente lo veas necesario. Además, parte de nuestra filosofía es no desarrollar herramientas que simplemente queremos desarrollar, sino solo herramientas que vemos como necesarias. Preferimos confiar en otras herramientas de código abierto y también contribuir a ellas. Pero cada vez que vemos que la biblioteca no se mantiene o no puede aceptar las cosas que necesitamos de ella, solo entonces creamos una nueva biblioteca. O lo que hacemos muchas veces es tomar bibliotecas sin mantenimiento y revivirlas.

Así que al comienzo de este año, vimos mucha necesidad en el ecosistema del servidor de GraphQL. Intentamos descubrir qué necesitamos y cómo podemos mejorarlo. Intentamos contribuir y tener conversaciones con los frameworks existentes en la comunidad. Y terminamos creando nuestra propia solución. Así que hoy quiero hablarles sobre Envelope. También deberías visitar el sitio web y echarle un vistazo allí. Pero hoy quiero comenzar realmente con cuál fue nuestra mentalidad cuando comenzamos a crear Envelope. Entonces, lo primero que nos preguntamos, al observar el ecosistema existente, fue qué necesitamos realmente de un servidor de GraphQL. Quiero decir, esta es una diapositiva que uso en muchas, muchas de mis charlas.

Básicamente, aquí vemos que un cliente realiza consultas a un servidor GraphQL, el servidor GraphQL luego realiza llamadas a todo tipo de fuentes y lugares, y el servidor me devuelve un resultado, orquestando todas las llamadas y enviándome un resultado como espero. Esto es algo que todos conocemos. ¿Cuál es el mecanismo aquí y qué necesitamos de él?

Entonces, el núcleo de esto es GraphQL JS en sí, la implementación de referencia y la implementación de referencia. En realidad, si miramos el código interno, básicamente expone un par de funciones para nosotros. Validate, parse, execute y subscribe. Validate se encarga de validar el esquema y la consulta para asegurarse de que sea un esquema y una consulta válidos. Parse analiza la consulta como AST y la comprende, convirtiéndola en un documento que podemos ejecutar. Y luego la función execute en sí misma, de la cual he dado muchas charlas sobre cómo se ve por dentro. Esta es como una diapositiva de seudocódigo sobre lo que realmente sucede dentro de la función execute, es decir, la función execute recibe el esquema ejecutable y la consulta, y luego realiza toda la orquestación y el trabajo de automatización para obtener el resultado correcto en la forma que queremos, orquestando todo lo que sucede con las llamadas de red o los resolvers. Eso es básicamente la función execute y GraphQL JS. Esas son las cosas que GraphQL JS nos brinda. Pero luego está el servidor. ¿Qué son las cosas adicionales que GraphQL JS no nos brinda y que necesitamos de un servidor GraphQL?

Una cosa es la creación del esquema en sí. GraphQL JS tiene su propia forma de crear el esquema, pero la comunidad realmente se ha diversificado y ha creado muchas soluciones diferentes para crear un esquema, como el enfoque SDL-first, el enfoque code-first con herramientas como Nexus o GraphQL, que es muy emocionante y vale la pena explorar, y muchas otras. Entonces, quieres crear tu propio esquema de muchas maneras diferentes. La otra cosa que necesitamos para conectar GraphQL JS es en realidad la capa de comunicación. Necesitamos conectarlo a un servidor HTTP, tal vez trabajar con WebSockets y tal vez queremos implementarlo en un entorno serverless y necesitamos todo tipo de restricciones y cosas allí. Y queremos que nuestro servidor GraphQL se encargue de eso por nosotros. Y hay muchas, muchas cosas diferentes en torno a la operación de este servidor GraphQL, como el almacenamiento en caché y el rendimiento, el seguimiento, el registro, la seguridad y la autenticación, y un buen manejo de errores. Y, por supuesto, queremos que el servidor GraphQL tenga un ecosistema próspero. Queremos que las personas puedan crear muchas soluciones diferentes en el servicio GraphQL para que podamos usarlo en cualquiera de nuestros casos de uso y no depender de un solo caso de uso que sea lo único que necesitamos para nuestro servidor. Una vez que descubrimos eso, observamos el panorama actual y esta es una diapositiva muy opinada. Puedes discutir con nosotros, me encantaría. Pero creemos que el ecosistema actual de servidores tiene algunos problemas. En primer lugar, los marcos de trabajo más populares actualmente son muy opinionados y a veces no están bien mantenidos. Y creo que la combinación de estos dos es muy problemática. En primer lugar, ser muy opinionado significa que te ajustas a ciertos tipos de casos de uso, generalmente casos de uso simples, y porque quieres obtener mucha comunidad y cosas así. Pero luego, si combinas eso con una biblioteca mal mantenida, significa que ahora tus usuarios no pueden cambiar las cosas y no pueden mantenerse actualizados. Juntos, esta es una situación muy problemática. Y esto es algo con lo que nos enfrentamos mucho cuando trabajamos con nuestros clientes.

Necesitábamos una configuración mucho más compleja y manejar todo tipo de casos. Y las bibliotecas actuales simplemente no eran suficientes. Era muy, muy difícil de mantener. Y tuvimos que escribir mucho código extraño para hacer que las cosas funcionaran.

Además, los marcos de trabajo mantienen una forma específica de construir las cosas. Y muchas de las soluciones que proporcionan no se comparten entre diferentes tipos de servidores HTTP o diferentes formas de crear el esquema. Por ejemplo, si estás utilizando el enfoque code-first o schema-first. Todo lo relacionado con el servidor podría ser compartido sin importar cuáles sean tus elecciones, pero en muchos de estos marcos de trabajo, debido a que son opinionados, no puedes hacerlo.

Otra cosa es que estos marcos de trabajo envuelven todo el pipeline de solicitud. Esto está bien si estás haciendo algo muy simple. Pero en primer lugar, depende. A veces, si trabajas con un servidor HTTP como Festify, Express o Coa, quieres aprovechar al máximo sus capacidades. Y en segundo lugar, a veces estás implementando en entornos diferentes. Y quieres tener la máxima flexibilidad, como en implementaciones en el borde con CloudFlare Workers, y necesitas más flexibilidad en cómo manejar estas cosas. Quieres conectarte a este sistema y tener todo el poder para implementarlo en cualquier lugar. Algunos marcos de trabajo permiten extensiones mínimas y cosas así, pero en nuestra experiencia, esto fue muy, muy difícil de trabajar.

Seguimos intentando contribuir, seguimos intentando ayudar a mejorar las cosas, pero en algún momento llegamos a un límite. Y también hubo otra cosa, donde algunos de los marcos de trabajo están construidos para un propósito específico. Están diseñados para que uses más herramientas de estas empresas. Y eso significa que también se refleja en las elecciones técnicas. Y eso significa que es difícil utilizar soluciones personalizadas que a veces son necesarias para aplicaciones complejas con estos marcos de trabajo de servidor y sus arquitecturas.

Así que volvimos a la mesa de dibujo y lo que ves aquí es en realidad el primer boceto que hicimos de Envelope. Intentaré explicar lo que estábamos pensando en ese momento. Tomamos GraphQL JS y tomamos las funciones que expone: parse, validate, execute y subscribe. Y pensamos, ¿qué pasaría si pudiéramos conectarnos al sistema? Podríamos tal vez conectarnos antes y después del parseo, antes y después de la validación. Ocho funciones antes y después de todo esto. Así que podríamos cambiar cualquier cosa y aún así exponer la misma API. Entonces, cualquier persona que use solo GraphQL, la implementación de referencia, aún podría usar lo mismo, pero ahora tenemos ganchos en el sistema con un poderoso sistema de plugins. Cada plugin podría conectarse a cada uno de estos pasos de GraphQL. Y también conectamos básicamente, simplemente te dimos la opción de proporcionar tu esquema.

Entonces, y ese esquema podría ser cualquier cosa, podría ser Nexus, podría ser geográfico, podría ser schema first con herramientas de GraphQL y también federación, de la que tal vez mencione más adelante. Y luego, todo esto está separado de la solicitud, el pipeline de solicitud HTTP.

Entonces, cuando manejas el pipeline de solicitud HTTP, lo dejamos en manos de las mejores herramientas que hacen ese trabajo, como Fastify, Express, Coa, y también en otros entornos como entornos serverless. Así que tienes todo el poder y simplemente usas estos frameworks como se pretende, no hay razón para que hagamos un mejor Fastify o envolvamos Fastify para ti.

Entonces eso es Envelope. Y eso es lo que lanzamos hace aproximadamente un año. Esto fue un cambio de juego para nosotros. Eliminamos mucho código al trabajar con clientes que utilizan el sistema. Y hoy en día, el ecosistema que lo rodea es enorme y ahora compartiré por qué. ¿Cuáles son las cosas que realmente, que Envelope nos ayudó? Lo primero, hay muchas cosas gráficas difíciles que repetíamos y hacíamos una y otra vez con cada cliente. Y ahora, en lugar de repetir estas cosas y depender del cliente que depende de la configuración, ahora podríamos compartir, podríamos convertir esa lógica en un plugin y compartirlo en todo el ecosistema, todos nuestros clientes y todos nuestros usuarios de código abierto.

Aquí tienes un ejemplo cuando iniciamos un servidor Envelope. En este ejemplo, obtenemos un servidor extremadamente eficiente solo agregando tres plugins con tres líneas de código. Usamos la caché del analizador, usamos la caché de validación y usamos GraphQL JIT. Solo con agregar estas tres cosas, nuestro servidor básico se vuelve mucho más rápido que probablemente tu servidor hoy. Y como desarrollador de servidores, no necesitaste hacer mucho. Solo necesitabas elegir algunos plugins y agregarlos con una línea de código y eso es todo. Pero para el desarrollador de plugins, tenían una API muy poderosa para conectarse en cada paso del sistema. Y creo que esa es la potencia de Envelope. Para los usuarios, para los desarrolladores de servidores, es extremadamente fácil. Y para los desarrolladores de plugins, es extremadamente poderoso. No estás perdiendo. La simplicidad no interfiere con el poder.

Y ahora, en realidad podrías, y también cuando comenzamos a construir todos estos plugins, vimos cada vez más personas de la comunidad que realmente contribuían. Así que creamos un centro de plugins. Es un lugar donde puedes explorar y hay muchos, muchos plugins diferentes hoy. Para muchas cosas difíciles que la gente solía crear muchas charlas de conferencias y muchos artículos de blog al respecto, ahora es tan fácil como escribir un plugin. Hay plugins para el almacenamiento en caché, el seguimiento con lo que quieras, Prometheus, DataDog, New Relic, Sentry, OpenTelemetry, Apollo Tracing, Loggers. Puedes usar consultas persistentes, todo tipo de plugins relacionados con la seguridad, como límites de velocidad, límites de profundidad, análisis de costos, todas estas cosas y muchas otras. Nuevamente, obtienes un ecosistema muy rico que puedes usar con las elecciones tecnológicas que desees hacer.

Entonces, y eso me lleva al segundo punto, que ahora podemos resolver cada problema una vez con un plugin y compartirlo en todo el ecosistema, lo cual es una idea muy poderosa que, por alguna razón, no se había hecho hasta ahora. No importa dónde implementes, un servidor Envelope puede usar los mismos plugins y ser implementado utilizando cualquier servidor HTTP y en cualquier entorno, incluidos los trabajadores de CloudFlare en el borde, que es lo que solemos hacer. Esto es extremadamente poderoso. También puedes usar cualquier esquema que desees, incluido, por cierto, Apollo Federation.

Entonces, con algunos clientes que tenemos que utilizan Apollo Federation, en realidad reemplazamos el Apollo Gateway. Simplemente, tomamos el Apollo Gateway en su lugar, lo quitamos de los servicios federados existentes y lo reemplazamos con Envelope con soporte para Apollo Federation. Y ahora obtenemos tanto los beneficios de Apollo Federation como todo el poderoso sistema de plugins del ecosistema. Y eso fue realmente genial de hacer.

La tercera cosa que creo que fue realmente genial con Envelope es que ahora se convirtió en un marco para marcos. Puedes usarlo tal cual, pero también es un sistema de plugins muy poderoso. Ahora, todo tipo de marcos diferentes podrían construirse sobre la misma infraestructura central. En lugar de simplemente construir sobre GraphQL-JS, tienen el sistema de plugins de Envelope. Cada marco puede elegir sus opiniones y facilitarlo para ti, pero aún así compartir plugins y soluciones. Hay muchos ejemplos diferentes de marcos que ya funcionan con Envelope. El más famoso que probablemente verás hoy y hay una charla más tarde en GraphQL Galaxy es Redwood-JS.

Redwood es un marco increíble. Puedes construir aplicaciones extremadamente rápido con esto. Y al principio, se basaban en Apollo Server. Y luego, por todo tipo de razones, decidieron agregar también el soporte de Envelope. Una vez que agregaron el soporte de Envelope, su idea inicial era dar a los usuarios opciones para usar Apollo Server y Envelope. Pero después de un mes de usar Envelope, simplemente eliminaron por completo Apollo Server. Y ahora, con su versión 1.0, están completamente en Envelope. Y escribieron una publicación de blog increíble sobre por qué, y también publicaciones en el foro sobre por qué lo hicieron. Y creo que deberías leerlo porque hay muchos beneficios al hacerlo. Y vienen muchos más marcos. Puedes usar Envelope tal cual, pero también puedes usar marcos que se basan en Envelope. Y hay una cosa más que mencionaré pronto.

Otra cosa que vimos es que cuando comenzamos a usar Envelope y a compartir estos fragmentos de código y plugins, muchos de nuestros clientes son en realidad grandes corporaciones y quieren tener una cierta uniformidad. Tienen muchos equipos que están construyendo sus propios servidores GraphQL y también son responsables de implementarlos y mantenerlos, pero quieren tener algún tipo de conformidad. Por ejemplo, una forma de registro o, ya sabes, guardar trazas, o todo tipo de reglas de seguridad que desean compartir entre todos los diferentes equipos y todos los diferentes servidores GraphQL que tienen.

Lo que creamos fue algo así como un sobre de sobres para que puedas crear básicamente un plugin base que tenga todos los diferentes, todos los plugins compartidos en tu empresa, y luego puedes compartir eso en todos los servidores diferentes y los servidores pueden agregar y personalizar sus propios plugins. Pero ahora básicamente has creado un servidor potente que tiene toda la infraestructura compartida en toda tu organización.

Un ejemplo es Klarna, uno de nuestros grandes clientes, y recientemente tuitearon y hablaron sobre cómo trasladaron toda su infraestructura a Envelope y las cosas increíbles que les hizo, cómo les ayudó en toda la empresa. Hay muchos más casos como este, y espero compartir pronto más y más de estos estudios de caso y muchas empresas que hicieron esa transición.

Pero lo último que es realmente genial con Envelope es que también actúa, porque nos estamos conectando al sistema, también puede actuar como básicamente un Babel para GraphQL. Entonces, si piensas en el ecosistema de JavaScript durante muchos años, hemos estado usando todo tipo de características que no necesariamente son compatibles con todos los navegadores que no están en la especificación. Pero ya los usamos gracias a herramientas como Babel y muchas otras. Con Envelope, ahora tenemos la misma capacidad, pero con GraphQL. Específicamente, en The Guild lo hemos estado usando durante más de un año en todos nuestros servidores, estamos usando defer y stream, consultas en vivo con las directivas únicas y muchas otras herramientas muy poderosas y muchas primitivas de GraphQL muy poderosas que aún no están en la especificación. Lleva tiempo que las cosas se incluyan en la especificación y por buenas razones, pero eso no significa que no puedas y no debas usarlas. Todas estas herramientas son extremadamente poderosas y han mejorado mucho la forma en que escribimos servidores de GraphQL. Y gracias a Envelope, puedes usarlas hoy mismo.

Para obtener más información sobre Envelope, debes visitar nuestro sitio web, también en YouTube, tenemos un enlace de YouTube allí en la parte inferior. Puedes encontrar una charla que di en la que, en 15 o 20 minutos, inicio un servidor desde cero sin una sola línea de código y lo convierto en un servidor completo con defer y stream y soporte de consultas en vivo. Deberías ver la charla y, por supuesto, también la documentación y comenzar a usar Envelope. Pero hoy tengo una sorpresa más. Envelope, como dije, es un marco de frameworks. Y en The Guild, siempre intentamos ser, comenzar con lo básico y ser abiertos y muy flexibles y no ser demasiado dogmáticos. Pero si algunas personas en la comunidad conocen este símbolo y lo que representa, durante muchos años tuvimos básicamente un marco de GraphQL muy famoso en la comunidad, se llamaba GraphQL Yoga. Era extremadamente simple, el objetivo de este marco fue construido por Prisma. Y su objetivo era hacerlo lo más simple posible para iniciar el servidor de GraphQL. Realmente empujó en ese momento el límite de lo fácil y simple que es iniciar un servidor de GraphQL. Prisma se enfocó en otras empresas y se alejó un poco de esto. Pero fueron muy amables al trabajar con nosotros y entregarnos GraphQL Yoga. Y hoy estoy muy feliz de anunciar que acabamos de lanzar la primera versión alfa 2.0 de GraphQL Yoga que puedes comenzar a usar hoy. La idea aquí es que GraphQL Yoga, básicamente, construimos GraphQL Yoga como un envoltorio alrededor de un envoltorio con opiniones alrededor de Envelope. Entonces puedes disfrutar de todo lo que acabo de decir sobre Envelope, pero aún así comenzar de manera extremadamente fácil y básicamente tener un marco con todo incluido que tiene, no solo las herramientas que se incluyen de fábrica, obtienes soporte de suscripción de GraphQL, soporte de defer y stream, soporte oficial y actualizado de GraphiQL en localhost. No necesitas tener GraphiQL en la nube ni nada por el estilo. Y es moderno, está actualizado, es extremadamente eficiente. Aún es muy flexible porque aún puedes personalizarlo por completo gracias a los plugins de Envelope.

Y lo más importante es que al igual que todas las bibliotecas de The Guild, esto se mantendrá a largo plazo. Durante los últimos cuatro o cinco años, básicamente mostramos a la comunidad que todas las bibliotecas que mantenemos están ahí a largo plazo. Y ahora finalmente, tenemos un servidor GraphQL, un marco completo de servidor GraphQL que está aquí para quedarse y mejorar cada vez más y más. Y ya es el mejor en la comunidad. Así que espero que lo pruebes. Solo busca GraphQL Yoga en Google, accede al repositorio y acaba de lanzarse la versión alfa 2.0 y queremos tus comentarios.

En resumen, pensamos que te mereces y el ecosistema merece un mejor ecosistema de servidores cuando realmente entras en producción. Siempre fue muy fácil comenzar. Pero cuando entras en producción, las cosas empezaron a ser un poco menos flexibles y un poco menos potentes. Así que ahora gracias a Envelope y YOGA, obtienes un servidor GraphQL moderno. Puedes aprovechar el poder de la comunidad abierta. No necesitas depender de un determinado ecosistema. No necesitas depender de GIL. Hay todo un ecosistema de plugins. Nuestras herramientas y nuestras bibliotecas siempre están actualizadas y siempre bien mantenidas a largo plazo. Así que ahora la combinación de Envelope y GraphQL YOGA te brindará un servidor realmente potente en el que realmente puedes construir de manera segura. Sin mencionar que aún puedes usar todos los demás marcos en el ecosistema de marcos que aún se basan en Envelope, como Redwood JS, por ejemplo.

Muchas gracias por escuchar. Realmente espero recibir más comentarios sobre esto y porque estamos muy orgullosos en GIL de siempre estar ahí, siempre escuchando a la comunidad y mejorando según las necesidades de la comunidad y no solo por ideas aleatorias que tenemos. Muchas gracias y que tengas una excelente conferencia de GraphQL Galaxy, todos. Vamos a ver los resultados de la sesión de preguntas y respuestas inversas donde Juri te hizo una pregunta. Así que Juri, hola, gracias por unirte a mí en el escenario. Echemos un vistazo a los resultados. Y el ganador es Apollo. ¿Eso es lo que esperabas? En realidad, no, pero creo que Apollo en realidad el servidor de Apollo no admite la transmisión actual. Creo que tienen un problema abierto al respecto, pero aún no lo admiten. Según las respuestas que podemos ver aquí, creo que en realidad- creo que este es el mejor. Sí, el emoji es el correcto. Sí, en realidad, la mayoría de las respuestas aquí son del ecosistema de JavaScript. No estoy seguro en realidad si Azure admite defer aún o no.

En realidad, no estoy seguro de eso, pero Envelope y GraphQL-Leoga admiten defer y stream, junto con otras nuevas características de GraphQL que, aunque no están en la especificación, forman parte de Envelope. Es como el Babel de GraphQL, por lo que puedes usar características que aún no están en la especificación y usarlas desde hoy. Ya lo hemos estado usando durante algunos meses, especialmente defer, que es una característica muy poderosa y nos gusta mucho. Si alguien vio la charla de relay en la conferencia de React ayer, relay tiene soporte para defer, por lo que si quieres usarlo, definitivamente puedes hacerlo con Envelope en GraphQL Yoga. Genial. Bien, pasemos a las preguntas y respuestas reales. Tenemos una pregunta de Alexander Vaurvik, quien también hablará más tarde hoy. ¿Existen características específicas del lenguaje JavaScript en las que el sistema dependa? ¿Crees que este método de trabajo se podría aplicar a otros lenguajes? Sí, esa es una excelente pregunta. Creemos que sí, y también tenemos planes. Una de las cosas que queremos hacer es, en primer lugar, que otras personas de la comunidad de otros ecosistemas vean este enfoque, porque creemos que el enfoque en sí mismo debería ser genial y debería ser copiado por otros marcos en otros lenguajes. Pero también tenemos planes para agregar complementos a la ejecución de GraphQL de una manera independiente del lenguaje. Aún estamos en proceso y tenemos algunas pruebas de concepto, pero definitivamente es algo en lo que estamos pensando, y si alguien está desarrollando un marco para otros lenguajes en este momento, o por cierto, otros marcos para JavaScript, háblenos. Nos encantaría ayudar y compartir la idea, obtener comentarios y trabajar juntos para llevar esta idea a la mayor cantidad de personas posible y mejorar todo el ecosistema, por supuesto. Bien. Gracias, Yuri. La siguiente pregunta es de Danny. Danny Z. Una de las limitaciones que vemos al usar Helix y Envelope es la falta de algo como Apollo Studio. ¿Por qué sucede esto? Nuestros probadores están acostumbrados a realizar operaciones de prueba directamente en Studio. La pregunta que tengo es si The Guild tiene planes de tener un servicio similar a Studio. Sí, hay algunas cosas al respecto. En primer lugar, puedes usar GraphQL Studio con Helix y Envelope. El punto principal de todas las herramientas que creamos en The Guild es que funcionan con cualquier cosa. No estamos bloqueados por proveedores. Entonces, en realidad, con Envelope, tenemos un complemento para Apollo Tracing, por ejemplo, y puedes usar todas las diferentes herramientas de Apollo, incluyendo, por cierto, una cosa que estamos haciendo con nuestros clientes que utilizan Apollo Federation es que reemplazamos el Apollo Gateway con Envelope. Entonces, en realidad, tomamos la pieza de Apollo Federation que combina los esquemas y los ejecuta y todo, y lo ejecutamos dentro de Envelope. Así que obtienes lo mejor de ambos mundos, obtienes todos los complementos de Envelope y Apollo Federation. Por lo tanto, en cuanto a la primera parte de la respuesta, es posible usar Helix y Envelope con todas las herramientas de Apollo. Si tienes algún problema con eso, avísanos. En cuanto a la segunda pregunta, si tenemos planes de tener algo similar a Apollo Studio, no solo tenemos planes, en realidad tenemos algo que se llama GraphQL Hive, y es un servicio que básicamente es un registro de esquemas y hace muchas cosas, como rastrear tus solicitudes en vivo y decirte cuándo puedes deprecarlas, mostrarte cuáles son nuestras consultas más lentas. Se conecta a Datadog, Century y otros servicios. Así que sí, definitivamente también echa un vistazo a GraphQL Hive. Bien.

Bien, nos queda un minuto. Así que voy a hacer una pregunta breve que fue formulada por Alexander, nuevamente, yo, y otro usuario anónimo. ¿Qué utilizaste para crear las increíbles animaciones en tus diapositivas? En realidad, el crédito no es para mí. Yo soy, digamos, el que lo dibuja en un trozo de papel y se ve horrible. Y luego tenemos un diseñador independiente que trabaja en eso. Su nombre es Idan Avshalem y es increíble. Él me ha estado ayudando durante años a hacer estas diapositivas. Sí, es realmente bueno que pueda pensar visualmente porque soy un pensador visual. Y luego puedo llevarlo a las diapositivas y explicárselo a la gente. Ha sido de gran ayuda para mí. Pero él no está disponible porque trabaja exclusivamente para ti, ¿o la gente puede contratarlo? No, no, está disponible para contratar. Si alguien quiere contactarlo, solo avísenme. Es increíble, lo recomiendo mucho para todos. Sí. Y toda la ejecución real de sus diseños se realiza en Keynote. Como todas las animaciones y todo lo que se mueve. Es Keynote y él lo creó. Así que sí, lo recomiendo mucho. Pensé que lo había hecho en After Effects.

Bien, Jurri, ¿es todo el tiempo que tenemos? No. Así que muchas gracias, por supuesto, por unirte a nosotros aquí hoy. Creo que todavía te unirás más tarde para la sala de discusión, ¿verdad? O charla relámpago, sala de discusión. Sí, estoy participando en un par de discusiones en grupo. Muchas gracias por tenerme. Muy bien, Jurri, nos vemos entonces, adiós adiós.