Rompiendo las Cadenas de REST: Un Camino de Fastify y Mercurius hacia la Gloria de GraphQL

Hola, y bienvenidos a esta charla sobre cómo construir un servidor GraphQL utilizando Fastify y Mercurius.

Así que, en primer lugar, permítanme presentarme. Soy Luca Del Pupo, un desarrollador de software científico en Neo4m y un entusiasta de JavaScript y Typescript. En mi tiempo libre, intento llevar adelante mi canal de YouTube y también escribo publicaciones técnicas para personas de tecnología. También me encanta correr, hacer senderismo y las mascotas, pero ahora es hora de adentrarnos en el tema de hoy.

¿Por qué GraphQL? Básicamente, cuando comenzamos a trabajar con API, comenzamos con SOA y luego pasamos a la API REST , pero solo servimos aplicaciones de escritorio o aplicaciones de navegador de escritorio. Pero hoy en día, tenemos que servir diferentes tipos de dispositivos, como móviles, relojes inteligentes y televisores. Y en algunos casos, la API REST es una limitación. Por ejemplo, cada dispositivo tiene su propia interfaz de usuario y diferentes necesidades, porque la computadora de escritorio tiene una pantalla grande, el móvil tiene una pequeña y el reloj inteligente tiene una bastante, bastante pequeña. Entonces, la información que puedes mostrar en este tipo de dispositivo es diferente. Y básicamente, lo que sucede es que el móvil necesita un subconjunto de los datos que se necesitan en la aplicación de escritorio, y lo mismo ocurre con el reloj inteligente. Y lo que sucede es que básicamente, la gente comienza a crear puntos finales específicos solo para eliminar los campos que no se necesitan, para mejorar también el rendimiento de la aplicación móvil y el tiempo que el servidor tiene que pasar para serializar y deserializar los datos.

Otro problema es que si estás en el navegador, tu navegador tiene una limitación en el tiempo de solicitud en el mismo momento en paralelo, y el número es 10. Entonces, en algunos escenarios, esto también es otra limitación que no puedes evitar si estás utilizando una API REST. Y este es Bill. Bill es un desarrollador junior de backend que lucha todos los días con el frontend y el móvil para construir un punto final específico para una sola vista que necesitan. Bromas aparte, la API REST no es un desastre, pero en algunos escenarios, no son la mejor solución para tu aplicación. Y por eso Facebook, ahora Meta, ha creado GraphQL.

GraphQL es un lenguaje de consulta que te permite crear un tipo de servidor que sirve diferentes tipos de dispositivos. Y si eres un buen desarrollador y lo construyes de la manera correcta, puedes utilizar solo un servidor y crear solo una API y servir diferentes tipos de dispositivos como escritorio, móvil, reloj inteligente, etc. GraphQL es bastante simple. Básicamente, contiene un esquema. Un esquema es como tu API abierta, ¿de acuerdo? Y dentro, puedes definir las consultas que son la forma de recuperar datos del servidor. Puedes definir mutaciones que son la forma de actualizar datos, eliminar datos o agregar datos en tu servidor. Y también hay suscripciones. También hay suscripciones que te permiten suscribirte a un evento. Y cuando algo sucede en el servidor, el servidor emitirá este evento y el cliente tal vez pueda reaccionar de alguna manera. No lo sé. Puedes usar una mutación para agregar un elemento al carrito. Y cuando esto sucede, puedes modificar el cliente que está suscrito a este evento.

Y tal vez puedas, en la interfaz de usuario, actualizar el distintivo del carrito en tu aplicación. Y de esta manera, puedes escalar tu servidor de manera fácil. También puedes usar GraphQL para fusionar diferentes microservicios. Por ejemplo, puedes decidir dividir tu servidor en diferentes microservicios, y también se pueden utilizar en el servidor GraphQL de SAP IE o en diferentes tipos de tecnología básicamente. Y luego puedes actualizarlos dentro de un solo servidor GraphQL y exponer solo este servidor GraphQL al cliente. Y por último, pero no menos importante, recuerda que cuando creas este tipo de solución, debes recordar que cada capa tiene un costo. Es un costo en términos de dinero, porque los recursos y la memoria, como la CPU, no son gratuitos. Pero también son un costo en términos de complejidad, porque mantener una capa que tiene que comunicarse con otra parte de la aplicación es un costo en términos de complejidad.

Por cierto, ¿por qué amo Mercurius? Básicamente, Mercurius es un adaptador de GraphQL de alto rendimiento construido sobre Fastify. Básicamente, en 2024, prefiero usar Fastify y Auto Express, porque es una decisión tomada en términos de seguridad y rendimiento. Mercurius tiene muchas características principales y complementos listos para producción, y solo tienes que decidir cuál quieres usar y usarlos en tu aplicación de la manera correcta. De forma predeterminada, Mercurius implementa las especificaciones de Apollo Federation que permiten crear diferentes microservicios y agruparlos en un gran microservicio. Y luego, Mercurius es de código abierto y tiene licencia MITA. Eso significa que puedes contribuir a él, puedes abrir un problema si quieres y también puedes solucionar el problema si quieres. Y hay una comunidad fantástica que permite que Mercurius siga lanzando nuevas características o solucionando algunos errores si los hay.

¿Cuáles son las características principales? Básicamente, Mercurius te permite almacenar en caché el análisis y la validación de la consulta, te permite evitar el problema N plus utilizando un cargador. Puedes usar un compilador en tiempo real para mejorar el rendimiento de cómo V8 compila tu función. Puedes usar suscripciones y federación, como dije antes. También puedes usar un gateway para agrupar diferentes servidores federados, o también puedes crearlos. Puedes habilitar la consulta por lotes y de esta manera puedes usar solo una solicitud HTTP para tener diferentes consultas en el resultado. O también puedes persistir algunas consultas porque en algunos casos puedes asignar un hash a una consulta específica que ya conoces y el cliente puede llamar directamente al servidor usando este hash. Mercurius entiende que el hash está relacionado con una consulta específica y devuelve directamente el resultado. Esto ayuda a prevenir problemas de tiempo real en el análisis y la validación de datos desde la solicitud. Porque uno de los problemas es que al usar GraphQL, uno de los problemas es que tu solicitud puede volverse grande en términos de tamaño de la solicitud.

Entonces ahora es el momento de ver la demostración. Hoy te mostré cómo puedes construir un servidor GraphQL utilizando Mercurius Fastify y TypeScript y luego resolver el problema N plus. Ahora déjame ir a mi GraphQL y luego ir a Visual Studio Code. Comencemos desde esta parte.

Este es el punto de entrada de la aplicación. En esta parte, debes crear tu aplicación Fastify, bastante simple. Obviamente, debes configurar TypeScript y todo ese tipo de cosas, pero para ejecutar la aplicación, debes crear tu aplicación Fastify, registrar el servidor y comenzar tu servidor, en este caso, en localhost y en el puerto 3000.

Dentro del servidor, debemos registrar otras dos cosas. En primer lugar, el complemento. En este caso, el complemento es bastante simple. Es un complemento simple de SQLite que nos permite tener una base de datos en memoria y guardar datos dentro de GraphQL utilizando categorías y publicaciones. También tengo algunas categorías y publicaciones prellenadas para acelerar la demostración. Luego, la segunda parte del servidor es la parte de GraphQL. Dentro de este archivo se encuentra el código de cómo podemos configurar Mercurius. Básicamente, debemos importar Mercurius y registrarlo dentro de nuestra aplicación. Debemos pasar el esquema, los resolvers, los loaders y si quieres habilitar o no GraphQL. GraphQL es una interfaz de usuario para probar y ver cómo probar en realidad tu servidor GraphQL.

El esquema, como puedes ver aquí, es una cadena simple que contiene el esquema de nuestra aplicación. En este caso, describo el tipo para la categoría que contiene la publicación y el tipo para la publicación que contiene la categoría. Y luego también defino una entrada que es el objeto para crear una nueva publicación en nuestro servidor.

Entonces, tengo que exponer la consulta y la mutación. Como puedes ver aquí, hay un tipo de consulta que contiene todas las consultas que quiero exponer al exterior. En este caso, getCategory, getCategory, getPost, getPost y getPostByCategory. Cuando devuelves una lista de data, es mejor agregar una paginación de ellas. Esto evita un problema en producción porque tal vez el servidor está ocupado deserializando y serializando cosas. O por ejemplo, la aplicación recibe miles y miles de data que tal vez solo necesitan 10 de ellas.

Y luego lo mismo para la mutación. En este caso, la mutación, hay dos mutaciones, una para crear la categoría y otra para crear la publicación. Bastante simple. Luego están los resolvers. El resolver es la forma de implementar nuestro esquema.

Como puedes ver, hay un objeto llamado consulta que contiene todas las consultas que describo en mi esquema. Como puedes ver, getCategory devuelve la lista de categorías. Dentro del tercer parámetro puedo tener el contexto. Dentro del contexto tengo la aplicación. Y dentro de la aplicación puedo obtener mi complemento para la database y llamar directamente a la consulta.

Luego, por ejemplo, también puedo obtener solo una categoría por ID. En el argumento, como puedes ver, tengo el ID de la consulta. Luego también te muestro cómo puedes generar tu definición de TypeScript a partir del esquema. Pero como puedes ver ahora, tengo todos los beneficios de TypeScript. Entonces, si intento llamar a esto, como puedes ver, tengo el ID. El ID es un argumento posible de mi consulta en este caso. Si intento llamar a name, como puedes ver, hay un error porque name en este caso está declarado pero nunca se usa. Pero básicamente, name no es una propiedad real del argumento, como puedes ver. Y luego, como puedes ver, es lo mismo para la paginación pero también es lo mismo para la mutación. Entonces, como puedes ver aquí, getCategory tiene el argumento y así sucesivamente. Puedes insertar los data y devolver los data.

Por último, pero no menos importante, está el loader. El loader es la forma de cargar la relación entre los tipos. Por ejemplo, como puedes ver aquí, está el tipo de categoría y esta es la forma en que puedo cargar las publicaciones de todas las categorías. Hay la publicación y esta es la forma en que puedo devolver la categoría de la publicación. Hablaré más sobre el loader en el próximo ejemplo cuando hablemos sobre el problema nplus.

Básicamente, ahora puedo ejecutar la aplicación que ya está en ejecución. Podemos volver a GraphiQL y, como puedes ver, podemos llamar a getCategories y obtener todos los resultados. O también podemos llamar a getPost y obtener todos los resultados. O tal vez también crear una categoría o crear una publicación usando esta nueva categoría. Bastante simple. Ahora, si vuelvo a Visual Studio Code, por último, pero no menos importante, también quiero mostrarte cómo puedes generar el tipo. Los tipos se generan utilizando un sencillo complemento llamado Mercurius Code Gen. Este complemento acepta la aplicación donde ya has registrado el complemento Mercurius y debes indicar la ruta de destino para tu tipo generado. En este caso, como puedes ver, uso el archivo generated.ts y dentro de mi archivo generated.ts, tengo todos los tipos generados basados en mi esquema.

Y de esta manera, tienes todos los beneficios de GraphQL pero también el beneficio de usar TypeScript. Además, tienes una única fuente del esquema. El esquema genera los tipos para ti y luego también se debe implementar el resolver basado en tu esquema.

De acuerdo, ahora es el momento de pasar al segundo ejemplo, el problema nplus. Básicamente, puedes usar el resolver o el loader para cargar la dependencia entre los tipos. Básicamente, esto es lo que puedes hacer. Antes de mostrarte el loader, ahora quiero mostrarte lo mismo pero con el resolver. Puedes usar el resolver y describir la categoría y la publicación. En este caso, como puedes ver, la categoría tiene una publicación y esta es la forma en que quiero cargar la publicación basada en la categoría. Dentro de este método, tengo la categoría y usando el ID, puedo cargar todas las publicaciones basadas en esta categoría. Lo mismo ocurre para la publicación.

Si vuelvo a mi terminal y ejecuto ahora el segundo ejemplo, puedo llamar a la categoría. Si llamo a la API de categoría, como puedes ver, llamé a la categoría una vez pero recuperé la publicación para cada categoría que necesito devolver. En este caso, la API devolvió las tres categorías y para cada API, tengo que llamar a este método. Esto significa que tengo que llamar a la base de datos tres veces. Lo mismo ocurre si llamo a la publicación, por ejemplo. Si llamo a la lista de publicaciones, como puedes ver ahora, llamo a la publicación y luego llamo a la categoría para el número de elementos que tengo que devolver para la publicación. Bastante simple de entender. Esto podría ser un problema en producción porque, como puedes imaginar, si tienes miles de elementos para devolver, llamas a la base de datos muchas, muchas veces. Eso significa que tienes que devolver la publicación y la categoría en consultas diferentes. A veces esto puede ser un lío.

Para resolver este problema, puedes usar el loader que ya hemos visto antes. ¿Qué sucede si habilito el loader? El loader tiene esta firma diferente. Puedes definir el tipo de categoría y cómo resolver la publicación. La consulta, en este caso, devuelve una lista de categorías. Recibes todas las categorías que deseas devolver para esta consulta. Puedes realizar esta consulta utilizando solo una consulta a la base de datos. Como puedes ver aquí, tengo solo una consulta utilizando el ID de la categoría. Luego tengo que devolver una lista de objetos donde cada índice es perfecto. El resultado para la categoría en el índice 0, el primer índice del resultado es la publicación para la categoría en el primer índice, y el segundo es la lista de publicaciones para la segunda categoría, y así sucesivamente. Usando esta solución, como puedes ver, lo que sucede es que si llamo a getCategories, ahora llamo a la API de categoría, la solicitud de la categoría una vez, y también solo una vez la consulta para recuperar todas las publicaciones.

Con esto, vemos toda la demostración. Ahora es el momento de pasar a la conclusión. Así que ahora, está bien, podemos ir a la conclusión, y ahora, está bien, quiero decir algunas cosas. La primera es no odiar las API REST, son increíbles, pero en algunos escenarios no son la mejor solución. Usando GraphQL, puedes construir uno y usarlo para todos. Pero también, esto no siempre es cierto, dependiendo de cómo construyas tu servidor GraphQL.

Luego, construir un servidor GraphQL utilizando Mercurius es realmente pan comido, y no olvides que todos los beneficios que tienes al usar Fastify, también los tienes si usas Mercurius. Ten cuidado con el diseño de tu aplicación porque entender lo que sucede en tu sistema puede ser complicado a veces. Cuando construyas tu consulta, recuerda tener cuidado con lo que deseas exponer a tu desarrollador frontend y darles solo el poder adecuado que deseas darles. Por favor, no olvides agregar una capa de monitoreo a tu aplicación porque es importante realizar un seguimiento de lo que sucede en tu aplicación.

Ahora he completado mi presentación, así que si quieres, aquí están los enlaces de las diapositivas a la izquierda y los enlaces del código a la derecha. Si quieres algo para leer, puedes seguir estos recursos. Fastify y Mercurius tienen documentación. Puedes visitar el blog de NearForm o también el blog de backend cafe. Si quieres algo para ver, hay algo para ver en nuestro canal de YouTube de NearForm o también en el canal de YouTube de Adventure in Nordland que es dirigido por Matteo Colina. Si quieres algo para leer como un libro, este es un libro fantástico sobre Fastify y hay también un capítulo sobre Mercurius. Eso es todo.

Estos son mis contactos y si quieres chatear conmigo, están abiertos. Puedes enviarme un mensaje sin ningún problema. Si quieres seguirme en mi canal de YouTube, este es el nombre, y también esta es mi cuenta de DevTO. Si quieres, trabajo para NearForm y estamos contratando. Si quieres unirte a nosotros, avísame. Por último, pero no menos importante, muchas gracias por estar aquí conmigo hoy. Espero que hayas disfrutado esta charla y si tienes alguna pregunta, estoy aquí. Gracias de nuevo y nos vemos pronto. Adiós, adiós.