Full-stack JS hoy: Fastify, GraphQL y React

Estoy muy contento de estar aquí. Gracias a todos. Hablaré sobre cómo construir una aplicación de pila completa moderna con JavaScript y, como pequeño adelanto, hablaremos sobre GraphQL, todo de código abierto, porque eso es lo que amamos. Mi nombre es Cody, trabajo en NearForm, enseño un curso de desarrollo web en la universidad local donde vivo en Francia, pero dejemos de hablar de mí. Lo que realmente quiero hacer es desafiar a todos aquí, hacer un pequeño ejercicio conmigo.

Cierra los ojos e imagina tu próximo proyecto. Tienes todos los requisitos de tus interesados, sabes lo que quieres construir, ¿y qué vas a hacer cuando cierres los ojos? Vas a empezar a pensar en esas herramientas y esos frameworks a los que vas a recurrir. Cuando hago esto y empiezo a pensar en esas herramientas y frameworks, me digo a mí mismo que esta vez será diferente. Esta vez será correcto, esta vez habrá arcoíris y esta vez habrá unicornios.

Creo que todos hacemos eso porque queremos utilizar nuevas tecnologías que nos ayuden, que resuelvan todos esos problemas que tuvimos en nuestro último proyecto. Sin embargo, creo que la trampa está en que podemos llegar al 80% de nuestro proyecto. Cuando llegamos a ese 80%, de repente algo sucede. Esas necesidades no funcionales del mundo real afectan ese último 20%, y ese último 20% es realmente difícil. ¿Dónde nos encontramos? Estamos pensando en arcoíris y unicornios, terminamos con algo como esto. No sé cuántas veces he estado así, tratando de solucionar problemas reales en una aplicación en producción. Tenemos tuberías de CI complejas, tenemos problemas de escalabilidad, tenemos problemas de rendimiento, de seguridad, cosas en las que no pensamos al principio, autorización, autenticación, así que siento que hay una brecha enorme entre lo que imaginamos y la realidad, porque todos somos personas del mundo real solucionando problemas del mundo real. Somos desarrolladores, estamos tratando de hacer lo mejor que podemos, y creo que lo que quiero desafiar hoy es que nos centremos en ese último 20%, en ese difícil 20% que no siempre pensamos al principio.

Así que quiero hablar de este tipo. Este tipo, su nombre es Vilfredo Prado. Lo llamamos el Principio de Prado. Sé que no puedes leer ese texto, pero lo harás en un segundo. Vilfredo Prado, este economista italiano, ideó la regla del 80-20. Sigo hablando de estos porcentajes y él dijo que tal vez solo el 80% de nuestros resultados en nuestros proyectos provengan del 20% de los desafíos, de los requisitos. Eso es lo que quiero desafiarnos a hacer hoy. Pensemos en ese 20% desde el principio. Así es el Principio de Prado en su totalidad. Y creo que Steve Jobs lo sabía. Cuando regresó a Apple en 1996, tenían como 15 modelos de computadoras de escritorio, los redujo a uno. Tenían un montón de dispositivos portátiles, creo que los llamaban laptops en 1996, los redujo a uno. Periféricos, impresoras, los eliminó todos.

Después de deshacernos de todos ellos. Él quería centrarse en ese último 20 por ciento, ese último 20 por ciento que realmente importaba. Así que hoy, en lo que quiero centrarme, en lo que quiero desafiarnos a centrarnos es en ese difícil 20 por ciento. Y tal vez, solo tal vez, podamos obtener un 80 por ciento en nuestra productividad.

Entonces, ¿cómo podemos construir esta pila tecnológica, esta pila tecnológica mágica, que se va a centrar en ese difícil 20 por ciento, ese 20 por ciento de requisitos no funcionales, ayudarnos a obtener velocidad de entrega y asegurarnos de que nuestra aplicación de calidad de producción funcione de la manera que queremos, que podamos solucionar problemas mientras está en producción? Para hacer eso, quiero establecer algunos principios cuando vaya a construir mi pila tecnológica. Estos son los principios en los que voy a pensar. El primero va a ser la modularidad. Y creo que uno de los desafíos, las trampas en las que podemos caer, es que vamos a buscar ese marco de trabajo que dice que lo hace todo, y pensamos que lo hará todo, pero tal vez no lo haga todo. ¿Qué sucede cuando llegamos a ese momento en el que no hace algo que queremos y tenemos que recurrir a algo más, o desechar el marco de trabajo y comenzar desde el principio? Entonces, si podemos construir una pila tecnológica en la que podamos reemplazar capas de la pila cuando algo no funcione, hemos ganado algo, ¿verdad? Como si nuestra pila de repente se volviera modular y pudiéramos adaptarnos a la situación, a los requisitos a medida que evolucionan.

El siguiente principio en nuestra lista es la experiencia del desarrollador. Por eso estamos aquí. Todos somos desarrolladores. Todos estamos solucionando problemas reales. Quiero herramientas que me ayuden, que me guíen, que no me obstaculicen, ¿verdad? Y quiero poder ejecutar mi aplicación en cualquier lugar. Quiero poder ejecutarla en mi computadora portátil mientras estoy en el tren, cuando no tengo Wi-Fi o en el avión, como si necesitara ejecutarse localmente o en la nube, en el sitio, en Docker, lo que sea. Eso también es muy importante para mí. No quiero depender de algunos servicios en la nube y no poder ejecutar mis pruebas de extremo a extremo en mi máquina porque dependo de esa conexión a Internet que no existe en el hotel. Basado en mis principios, la comunidad es lo primero. Estoy hablando de proyectos de código abierto. Apoyados por la comunidad. Idealmente, serán más seguros, ¿verdad? Porque más personas, más ojos están mirando el código. Los errores se corregirán. Las cosas no se ocultan de ti. Creo que eso es realmente importante cuando se trata de una pila tecnológica. Estoy hablando de un 100% de código abierto. No solo ese 80% y el 20% de la fórmula mágica secreta se ejecuta en un servicio en la nube que nadie puede ver. Quiero ver un 100% de código abierto. Mi último y último principio será la transparencia. Esto está relacionado con el código abierto y esa idea de un proyecto respaldado por la comunidad.

También la transparencia, cuando hablamos de abstracción. Amamos las capas de abstracción. Eso es lo que facilita nuestras vidas. Eso es lo que nos hace productivos y nos permite desarrollar cosas rápidamente. ¿Qué sucede cuando la abstracción no funciona? Quiero poder quitar esas capas y meter las manos en los detalles más minuciosos. Las partes sucias. Como vimos en ese primer meme de personas arreglando cosas. Quiero poder acceder a esas abstracciones si es necesario. No deberían estar ocultas para mí.

Entonces hablemos de la pila. Ahora la pila. La mayoría de las personas, cuando comenzamos a construir una pila tecnológica, a menudo empezamos desde el frente y avanzamos hacia atrás. Creo que ese enfoque es incorrecto. Si queremos solucionar ese último 20% de los requisitos no funcionales, entonces debemos empezar desde el final. Eso es lo que hoy les desafío a hacer. Así que voy a darle la vuelta al problema por completo. Vamos a empezar por el final. Así que hablemos de la pila.

Verán esta diapositiva con los waffles bastante seguido. Los encontré bastante sabrosos. Así que los veremos a menudo en esta presentación. Entonces, lo primero en la pila, empezamos por el final. Pueden criticarme. Pueden enviarme su correo de odio. Tienen mi nombre de usuario de Twitter ahí. Pero amigos míos, hay un elefante en la habitación. Y el nombre del elefante es PostGrey. ¿Por qué hablaría de PostGrey? PostGrey es increíble porque las bases de datos relacionales, también amo las bases de datos sin esquema basadas en documentos. Pero los desarrolladores lo conocen. Y estoy dispuesto a apostar que en esta sala, cualquiera que tenga un título en ciencias de la computación o ingeniería de software, apuesto a que ha tomado un curso de bases de datos relacionales.

Apuesto dinero a que es así. Así que los desarrolladores lo conocen. Puedes agregar desarrolladores a tu proyecto sin muchos desafíos. Y creo que eso es realmente importante.

Lo siguiente, lo digo ahora mismo. Cítame en eso. Es la mejor base de datos relacional. No solo es la mejor base de datos relacional, también está lista para no-SQL porque han tenido soporte JSON, creo, desde la versión 9, y estamos en la versión 14 actualmente. Así que el soporte JSON solo mejora cada vez más. Entonces, si quieres construir una base de datos basada en documentos, puedes hacerlo en PostGrey. Esa es una de sus superpotencias.

El agrupamiento de conexiones, no voy a dedicar mucho tiempo a eso. Necesito acelerar un poco. Pero el agrupamiento de conexiones nos permitirá una escalabilidad increíble. Eso es otra cosa en la que tenemos que pensar cuando estamos construyendo esa gran pila tecnológica. Entonces podemos hacer agrupamiento de conexiones, podemos cortar de repente toneladas de recursos haciendo el handshake TLS si podemos compartir conexiones. Y la última cosa de la que quiero hablar es esa experiencia de desarrollo porque puedo ejecutar PostGrey, puedo iniciarlo en mi computadora portátil aquí en un segundo en un contenedor de Docker y puedo ejecutar todas mis pruebas directamente. Y, ya sabes, ámalo u ódialo. Tengo esa relación con SQL, pero es increíblemente poderoso. agregaciones en múltiples tablas, o si estuviéramos hablando de colecciones en una base de datos basada en documentos, puedo hacerlo.

Lo siguiente en la pila tecnológica de la que vamos a hablar es el servidor. Si vamos a hablar del servidor, vamos a hablar de Fastify. No pude evitar pensar en ese gato de Fastify comiendo algunos de esos waffles. Este es mi servidor node.js y está inspirado en happy. Será muy familiar para cualquiera que haya usado Express antes. Es fácil de usar. Y lo increíble de happy, Fastify, es que te permite construir una aplicación monolítica hoy cuando estás haciendo tu POC. A medida que tu proyecto crece y tus requisitos crecen, inevitablemente, vas a querer dividirlo probablemente en servicios, crear algún tipo de arquitectura de microservicios y Fastify, con esa arquitectura de complementos, te permitirá evolucionar con tu código. Entonces, la Ley de Conway siempre entrará en juego. Básicamente, tu código se verá como tu organización, y Fastify te permite hacer eso.

Es de código abierto, es transparente y es modular, porque tenemos esos complementos. Nuevamente, puede ejecutarse en cualquier lugar. Eso es una de las cosas que nos encanta de Fastify. Y esa arquitectura de complementos es como un Xen de programación cuando cada complemento está aislado de los demás, y puedes construir lógicamente tu aplicación.

Así que ahora vamos a la buena parte, nuestra capa de API. Será GraphQL. Si estamos usando GraphQL en el servidor de Fastify, vamos a usar Mercurius. Mercurius es un complemento de GraphQL, un servidor de GraphQL para Fastify. Y resolverá problemas reales de GraphQL hoy, como de manera predeterminada. Esto es lo genial de Mercurius. Admite caché, federación, autenticación, suscripción, carga de archivos, todas esas cosas que no pensaste cuando escribiste tu primer servidor GraphQL, vienen con esos en forma de complemento que son compatibles con el proyecto principal, o vienen con ellos de manera predeterminada. Eso es lo que es tan increíble. Y la caché, vamos a hablar de eso en un momento. La caché es realmente increíble en Mercurius, y eso es lo que nos dará un rendimiento increíble a medida que nuestra aplicación se escala. Integra el servidor GraphQL, por lo que obtenemos una línea de tiempo donde podemos ver nuestras consultas pasar y podemos depurarlas en nuestro navegador. Oh, lo siento, ese es el siguiente paso, me salté un paso. Eso nos permite depurar nuestras consultas en nuestro navegador mientras las estamos construyendo. Tiene soporte incorporado para cargadores. No tengo tiempo para entrar en eso. Inevitablemente, si alguien aquí ha construido un servidor GraphQL, tendrá ese problema donde sus datos están en un gráfico, por lo que tiene algún tipo de jerarquía. Si está obteniendo padres, eventualmente tendrá que obtener hijos. No quieres hacerlo uno tras otro. Quieres encolar a todos los padres y luego encolar a todos los hijos y tal vez hacer dos consultas a tu base de datos para obtener todos tus datos. Y el cargador te permite hacer eso, y eso viene incorporado en Mercurius y eso es una de las cosas que me encanta de usar Mercurius.

Vamos a cambiar al lado del cliente. Si vamos a usar GraphQL en nuestro cliente, ¿qué vamos a usar? Vamos a usar Urql. Yo lo llamo Urql. Tú puedes llamarlo U-R-Q-L. U-R-Q-L. Creo que Urql suena bien.

Es el mejor cliente de GraphQL. Funcionará con todas las principales bibliotecas de front-end. Estamos en React, por lo que admite React como su principal biblioteca de front-end. Almacenamiento en caché. Hace un almacenamiento en caché increíble. Almacena cosas utilizando tu consulta como clave en la caché, pero también puede normalizar tus data y almacenar cosas por ID, ID de la entidad. Esto te permite extraer elementos de la caché que ya han sido consultados por una consulta diferente. Y tiene soporte sin conexión. Si tenemos la capacidad de almacenar cosas en caché, podemos almacenarlas en la base de datos del índice en el navegador y nuestra aplicación de repente puede funcionar sin conexión. Todas las cosas que podríamos desear en un cliente de GraphQL, Urkle las tiene de serie. Y, por supuesto, tiene una API de hooks. Estamos aquí hablando de React. Es una API mágica y tienen algunas herramientas de desarrollo.

Así que tuve que incluir un par de fragmentos de código. Esto es realmente un componente, pero lo dividí en dos segmentos para que encaje en la diapositiva y vamos a construir una aplicación de pizza. Voy a tener slash pizzas en mi aplicación que va a listar todas mis pizzas. Probablemente tendré, como, slash pizza, slash un ID, para obtener detalles. Así que esta es la lista. Y tenemos ese hook useQuery. Supongo que tengo mi consulta a la izquierda. Y en la parte superior de mi componente, tengo el hook useQuery. Y eso devuelve un objeto de resultado que tiene estas tres claves en él. Data fetching error. Esto es increíble porque, como, la API está construida para escribir componentes React. Así que si hay un error, puedo mostrar una cosa, mostrar algo emergente. Puedo tener un spinner de carga. Súper fácil. Y finalmente, puedo renderizar mis data. Y si he configurado correctamente mi caché, si ejecuto esa consulta, y ahora voy a obtener detalles de una pizza, tengo una consulta similar a la izquierda. Esta vez voy a obtenerla por ID. Si he configurado correctamente mi caché, sabes, mi componente se ve más o menos igual a la derecha, solo tienes una consulta un poco diferente. De repente, como, Urkel nos permite obtener los data de la caché sin tener que ir al servidor, así que voy a visualizar esto muy rápidamente aquí. Así que tengo dos componentes a la izquierda. Mi componente de pizza y mi componente de pizza. Voy a hacer esa consulta. Va a recorrer la database. Va a volver. Pero las cosas se van a almacenar en la caché. Así que ahora lo que va a suceder, aunque si he configurado Urkel de la manera correcta, cuando finalmente haga esa consulta en el cliente, vendrá directamente en el lado del cliente de la caché. Sin viajes al servidor. Y esto, esto es increíble porque si, como, configuramos nuestras APIs de GraphQL para que coincidan con nuestro dominio empresarial y podemos almacenar cosas en la caché, como, imagina si, como, realmente no necesitamos preocuparnos por el estado de la aplicación, como, estado global, redux, todas esas cosas pueden complicar nuestra aplicación. Tuve que incluir esto aquí. Así es como me siento cuando no tengo que escribir código de redux.

Todos los días me siento así cuando no lo estoy haciendo. Entonces, por supuesto, estamos aquí en la React Summit. Tenemos que hablar de React. ¿Por qué amamos React? Bueno, porque es React. Y todos estamos aquí, como, los desarrolladores conocen React, por lo que podrás aumentar tu equipo, agregar recursos. Eso es una de las cosas que amamos de React.

Siempre está evolucionando pero, aún así, sigue siendo estable. Ok. La versión 18 tuvo algunos cambios que nos sorprendieron a todos, pero, como, estábamos preparados para eso, ¿verdad? Los componentes nos ayudan a arquitecturar nuestro código de manera correcta. Las herramientas de desarrollo, nos encantan. Vite. Si no estás usando Vite, úsalo. Ve a echarle un vistazo. Sí, si no lo estás haciendo, simplemente hazlo.

Así que una mención honorífica. Me estoy quedando un poco corto de tiempo, pero una mención honorífica aquí es SSR. Como, tenemos que hablar un poco de SSR. Ahora, lo increíble es que si estamos usando Fastify y Vite, hay un pequeño complemento para Fastify llamado Fastify Vite que nos permite hacer SSR, por lo que de repente tenemos una pila completa donde podemos hacer SSR y cada componente es modular, volviendo a esos principios. Funciona con todas las principales bibliotecas de front-end. Se encargará de la plantilla a nivel de página e integrará todas esas rutas que probablemente tengas en tu enrutador de React. Las agregará al servidor de Fastify para que podamos mapear nuestras rutas del lado del cliente en rutas en el servidor. Voy a ir muy rápido aquí, si alguien quiere hablar de esto conmigo, tenemos un stand, un stand de near-form aquí, ven a verme y podemos hablar de eso en más detalle. Es personalizable, no es mágico, es súper transparente. Una mención honorífica, mi colega Jonas Galvez, acaba de lanzar Fastify DX que va a tener React y Fastify Vite configurados y listos para usar, echa un vistazo a este proyecto, si no lo has hecho, todavía está en beta. Lo acaba de lanzar, creo, hace dos semanas, y va a estar listo para usar, teniendo todo configurado pero de una manera transparente que puedes personalizar.

Entonces, cuando comencé la charla, estábamos hablando de unicornios y arcoíris. Tal vez no podamos tener ambos. Si comenzamos a pensar en los problemas que inevitablemente tendremos en una aplicación en producción esos requisitos no funcionales, y los incorporamos en nuestra pila tecnológica desde el principio, aún podemos tener unicornios. Es posible que no tengamos arcoíris, pero aún tengo un unicornio. Así que solo quiero revisar esta pila muy rápido.

¿Por qué usaría esta pila? Como dije, está diseñada para esa funcionalidad compleja, esos requisitos no funcionales que van a surgir al final. Ese último 20 por ciento, estamos pensando en eso desde el principio, es altamente personalizable, podemos intercambiar cosas, aún tiene ese diseño modular.

Todas las capas de abstracción son transparentes, podemos quitar las cubiertas, podemos ensuciarnos las manos si es necesario, y por supuesto, es una community... Todos los proyectos son compatibles con la comunidad, de código abierto, tienen muchos ojos que los observan.

Entonces, eso es por qué usaría esta pila, y así es como vendo esta pila a tu equipo cuando están buscando ese marco que afirma hacerlo todo. Solo quiero hacerles una pregunta muy rápida. Tuvimos la pila lean, tuvimos la pila mean, tuvimos la pila jam. ¿Cómo se llama mi pila? Lo mejor que se nos ocurrió es Frump, Fastify, React, Urkel, Macarius, Postgre? No suena muy bien. Pensé en algo como firm o merf. Esos también son un poco extraños. Si tienes alguna idea, envíamela por Twitter o ven a verme al stand. Estaré encantado de hablar sobre eso.

Trabajo en NearForm. Como dije, tenemos un stand. Somos los mantenedores de algunos paquetes de código abierto realmente importantes y MPM, y brindamos servicios profesionales, pero también trabajamos en código abierto y contribuimos a él. Un lugar increíble para trabajar. Si quieres saber más sobre NearForm, visítanos en el stand. Estaré encantado de hablar sobre eso. Construí una aplicación de prueba de concepto, esa aplicación de pizza. Puedes echarle un vistazo en esta URL. También puedes ver mis diapositivas. Y si alguien tiene preguntas sobre estas cosas o quiere profundizar en los detalles, estaré encantado de hacerlo. Ven a verme al stand o contáctame en Twitter. Gracias a todos. Gracias. Pasemos a mi oficina. Vamos a la oficina. Eso está bien. En primer lugar, tengo un pequeño problema contigo. Tanta comida increíble en tus diapositivas, me estás dando hambre.

Bueno, ¡es hora de eso, ¿verdad? Genial. Vamos a pasar a esas preguntas. Recuerda, si quieres, también puedes encontrarlo en el stand y también en el stand de preguntas y respuestas justo después de esto. Pero vamos directamente a esa pregunta. Vamos a hacerlo.

La primera. ¿Es posible usar Fastify en una infraestructura serverless? Porque siempre estoy tratando de hacer las cosas serverless. Absolutamente fácil. La respuesta es sí. Es un gran sí. Ve al sitio web de Fastify y tienen un enlace directamente en la página de inicio para serverless, y te mostrarán cómo configurarlo. AWS, GCP, Azure, cualquiera que sea tu plataforma de servicio. Tienen instrucciones para configurarlo en todas ellas. Perfecto. Así que un gran sí. Increíble. Increíble.

Entonces hablemos de las ventajas de Ercu y Mercurius en comparación con Apollo, y vamos a combinarlas en dos. ¿Cuáles son las ventajas y desventajas de ambas? No quiero criticar ninguno de los frameworks existentes, pero lo que me encanta de Mercurius es que viene con todas esas cosas, esos pequeños detalles mágicos que tal vez no hayamos pensado cuando usamos los otros frameworks. Viene con ellos incorporados, listos para usar. Así que en el momento en que necesitemos hacer federación, o en el momento en que queramos hacer autenticación, o agregar almacenamiento en caché, simplemente viene incluido. Te lo entregan, está ahí mismo en el archivo readme, te dice cómo configurarlo. Esas son las cosas que me encantan de Mercurius y por qué trabajaría con eso.

Muy bien, muy bien. Y Ercu en el front-end, disculpen. Bien, y muchas personas que han utilizado muchos tipos diferentes de pilas, siempre trato de compararlas, hablemos de algunos de los inconvenientes y desventajas de esta pila para poder evaluarla con otras. Sí, creo que es una pregunta justa, definitivamente creo que es una pregunta justa. Los inconvenientes pueden ser la velocidad inicial de desarrollo, así que si optamos por un framework que afirma hacerlo todo, nos lanzará súper rápido a una alta velocidad de desarrollo, así que creo que eso definitivamente es una ventaja de un gran framework. Pero lo que quiero advertir a todos es que piensen en lo que va a suceder una vez que se implemente en producción, una vez que comiencen a surgir esos otros desafíos cuando tengan que solucionar cosas en un código de calidad de producción, ¿podrán hacerlo cuando estén utilizando ese gran framework? Hay ventajas y desventajas, creo que tal vez si dedicamos un poco más de tiempo al principio, podemos ahorrar mucho tiempo al final. Muy bien, muy bien, pero, ¿qué hay de React Query? Voy a pausar en esta pregunta, vengan a verme al stand, me encantaría hablar de ello en detalle con cualquiera que quiera, pero ahora mismo no tengo una buena respuesta para compararlo, hablemos de eso más tarde, por favor. Eso es bastante justo, y una vez más estamos volviendo a las comparaciones de pilas, Remix es otra pila de la que mucha gente está hablando. Sí, ha generado mucha expectación. No voy a compararla, porque no soy un experto detallado en Remix, como esta es la pila que uso todos los días, y podría hablar mucho sobre eso, estaría encantado de comparar algunos detalles en el stand, o en la sesión de preguntas y respuestas justo después, o contáctenme en Twitter, pero no quiero hacer una comparación paso a paso ahora mismo, aunque sé que es un tema candente. Totalmente, lo que sugiero es que aquellos que estén interesados en diferentes pilas, se acerquen al stand, tengan una gran conversación y puedan profundizar en ello. Sí, estamos entrando en detalles. Sí. Me encantan los detalles. Eres un gran fan de GraphQL. Sí lo soy. ¿Por qué? ¿Cuáles son algunas de las cosas que más te gustan de GraphQL? Realmente no sé por dónde empezar con esa pregunta, pero honestamente creo que lo que realmente me gusta de GraphQL es que estamos construyendo una abstracción sobre nuestro modelo de datos, y nos permite crear una capa de API que se adapta a nuestro dominio empresarial, y puede que no nos importe dónde se almacenan los datos, cuántos servicios almacenan esos datos. Si podemos usar GraphQL, podemos construir una API específica para nuestro dominio empresarial, y creo que eso es realmente importante. Por supuesto, tenemos versionado, podemos deprecar ciertas entidades, siempre podemos agregar propiedades a los objetos. Así que si lo comparamos con una API REST regular, todas esas ventajas están integradas. Esas son cosas que realmente me encantan de GraphQL. Hay más. Podría seguir hablando de esto durante un tiempo. Junto a esto, definitivamente. Muy bien, esta será la última pregunta. ¿Dónde y cómo se almacenan y manejan los tipos? Bueno, si hablamos de GraphQL, nuestros tipos se almacenan en un esquema. Así que escribimos un esquema en nuestro servidor que se cargará cuando carguemos Mercurius. Ahí es donde encontraremos nuestros tipos. Y como admitimos federación, podemos federar esquemas de diferentes servidores GraphQL, lo cual es una arquitectura realmente genial, porque tendríamos un servidor GraphQL que actúa como la puerta de enlace y puede federar esquemas de diferentes lugares. Así que podemos almacenar los tipos junto a los datos de donde se obtienen. Muy bien. Muchas gracias, Cody. Gracias. Realmente disfrutamos esto, aplaudamos. Gracias.