GraphQL con Mercurius y Prisma, amor a primera vista

Entonces, ¿por qué estoy aquí? Primero, porque el comité decidió votar por mi charla, así que gracias. Y luego, porque en el último período, intenté ayudar a un cliente a pasar de una API REST a GraphQL. Así que quiero compartir nuestra experiencia y cómo decidimos hacer el cambio de esta manera.

En los últimos 10 años, típicamente, solo he trabajado con API REST. Cuando comencé a trabajar, la API generalmente solo servía a navegadores o tal vez algunas aplicaciones de escritorio. Y las API REST funcionan muy bien de esta manera, en este caso, y se pueden usar sin ningún problema. No tengo ningún error o problema con las API REST porque funcionan muy bien y las uso a diario en este momento, pero en algunos escenarios, tenemos que mejorar la flexibilidad de la API. Típicamente, en el último período, comenzamos a utilizar otros dispositivos que utilizan nuestra API, por ejemplo, smartphones y también smartphones y smart TVs. Así que comenzamos a aprender el potencial de GraphQL porque necesitamos darle más poder al cliente, desafortunadamente. Y así comenzamos a aprender y probar GraphQL.

Antes de pasar a la decisión, también quiero mostrar la necesidad del cliente en este caso. Típicamente, trabajo con empresas pequeñas y medianas, y tienen muchos desarrolladores junior e intermedios. Y algunos desarrolladores senior. Las necesidades de este cliente son las siguientes, típicamente. Quieren un framework o una base de código fácil de mantener. Luego, el framework o la arquitectura deben ayudar en el día a día. Los desarrolladores deben ayudar a los junior, típicamente porque quieren aportar valor y aumentar sus habilidades, y también ayudar a los senior a no perder tiempo resolviendo problemas del framework. Bien. Luego, es imprescindible tener TypeScript en nuestra aplicación, y los desarrolladores deben enfocarse en el negocio y no en resolver problemas del framework. Entonces, con esta necesidad, decidimos hacer el cambio de esta manera, con Mercurius en la parte de GraphQL y Prisma para acceder a la base de datos y la parte del acceso a datos. El desarrollador se encuentra en el medio. Así que tengo que crear la firma de GraphQL y crear el código para acceder a la base de datos utilizando Prisma.

Luego, para la implementación de la base de datos, para la implementación del acceso a datos, decidimos pasar a Prisma. Normalmente, no me encantan los ORM, pero Prisma es un poco diferente en este caso. Nos ayuda a mejorar la experiencia del desarrollador del desarrollador, y también es fácil de usar y mantener. Y si estás familiarizado con TypeScript, la sintaxis para crear una base de datos y una capa de acceso a datos con Prisma, es bastante simple.

Luego, Prisma tiene una buena modelización de datos, por lo que es muy fácil crear tu entidad usando Prisma. Puedes crear consultas seguras en cuanto a tipos, por lo que puedes garantizar tu consulta durante el tiempo de compilación de tu aplicación si usas TypeScript. Y también puedes usar la migración para mantener actualizada tu base de datos en producción o en etapa, etc. Por último, pero no menos importante, puedes integrar Prisma en tu aplicación Fastify mediante un sencillo complemento, por lo que es muy fácil de integrar en un entorno de Fastify. Y por último, tanto Mercurius como Prisma aman TypeScript.

Así que hablo demasiado, así que quiero mostrarte la demostración para que puedas ver el código y entender los beneficios de la solución. Primero, ejecuto el servidor para que puedas ver la demostración en este caso. Ya te mostré la demostración antes en el... Está bien, más grande, no más grande. De acuerdo, mejor. Perfecto. De acuerdo, esto es GraphiQL. GraphiQL es una interfaz de usuario para probar o mostrar o ver la documentación de tu servidor GraphQL. Puedes usar los documentos si quieres y puedes verificar cuáles son las consultas en este caso. Puedes verificar cuáles son las mutaciones o cuáles son las suscripciones. Así que si quieres, puedes ver toda la documentación de tu servidor GraphQL. Luego también puedes probar tu aplicación. Por ejemplo, ya creé una consulta para un saludo. Así que este es un menú de pizza Tonino, lo siento, soy italiano y la pizza está en mi sangre. La primera consulta es el saludo. Así que es simple. Llamas a la consulta de saludo y el servidor responde con bienvenido a la pizza Tonino. También puedes crear una consulta con un parámetro si quieres. Bastante simple. En este caso, puedes llamar, HolaPupo. Paso el nombre, mi nombre en este caso.

HolaPupo, bienvenido a la pizza Tonino. Para ver un ejemplo más complejo que podemos hacer con la pizza. Ya he creado una pizza. Esta es la pizza para la Tortuga Ninja. Así que puedes ver la lista de pizzas. En este caso, la pizza es solo una, la pizza de pepperoni.

Y como puedes ver, puedes ver toda la implementación, puedes ver la lista de pizzas en el menú en este caso. También puedes, por ejemplo, crear una nueva pizza, la pizza margherita y así sucesivamente. Bastante simple. No quiero pasar demasiado tiempo en GraphQL porque no es el enfoque real del tema. Puedes crear pizzas y luego verlas en la lista de pizzas. Bastante simple en este caso.

De acuerdo, ahora quiero pasar al código para mostrar cómo podemos implementar este servidor GraphQL. Esta es mi aplicación. Quiero comenzar desde el lado de Prisma. Entonces, si quieres trabajar con Prisma, típicamente tienes que trabajar en una carpeta única llamada Prisma. Y hay solo un archivo. Está bien, el código es visible. Perfecto. El esquema de Prisma es el único archivo para trabajar con Prisma. Entonces, en este caso, el esquema de Prisma es la única fuente de tu base de datos. El esquema de Prisma es bastante simple. Hay una primera parte donde puedes ver el generador. El generador es el proveedor utilizado para construir tu cliente Node para llamar a tu base de datos. La fuente de datos es la información para entender cuál es el proveedor. En este caso, el proveedor es el Postgres SQL. Pero puedes usar MySQL, SQL Server y otros proveedores. La URL se utiliza para la cadena de conexión. Y luego, la otra parte importante es el modelo. Los modelos son las entidades de tu base de datos en este caso.

El esquema de Prisma te permite definir la estructura de las entidades y propiedades de tu base de datos. Puedes especificar el tipo de cada propiedad y agregar decoradores específicos, como la clave primaria o los valores predeterminados. La CLI de Prisma proporciona comandos como 'init' para inicializar tu proyecto, 'generate' para crear el cliente de Prisma y 'dev' o 'deploy' para las migraciones. Las migraciones se almacenan en la carpeta de Prisma, y puedes usar 'dev' para el modo de desarrollo y 'deploy' para producción.

La sintaxis, como puedes notar, es similar a TypeScript. El modelo indica que este modelo, el tema, es una entidad simple para la base de datos. Luego puedes describir tu columna o propiedad. En este caso, el ID, el nombre y el create-head, y así sucesivamente. Puedes indicar el tipo de la columna, en este caso, string, date, time, y así sucesivamente. Y puedes decorar cada propiedad con una decoración específica. Por ejemplo, el ID para la clave primaria, el valor predeterminado si deseas poner un UID predeterminado en tu entidad, y así sucesivamente.

También puedes crear relaciones para la clave de rango utilizando una sintaxis simple con la relación. Bastante simple, y si quieres mejorar tu experiencia de desarrollo, puedes instalar la extensión de Prisma en VS Code para obtener algo de intellisense, por ejemplo, puedes obtener ayuda para crear la columna, y así sucesivamente. Si comienzas a trabajar con Prisma, debes conocer cuatro comandos para la CLI. Típicamente, debes comenzar desde el mpx Prisma. Prisma es la CLI, y el init es el primer comando. Init se utiliza para inicializar tu proyecto en este caso, y ya lo he creado, así que no lo ejecuto. Luego, el segundo es el generate. Generate se utiliza para convertir el esquema en tu cliente de Prisma para llamar a la base de datos desde tu código base. Entonces, si lo ejecutas, Prisma comienza a leer tu esquema y crea el cliente de Prisma como un objeto. Hay algunos, está bien. Está bien, ahí está el cliente de Prisma que se utiliza para llamar a la base de datos y hacer la consulta, y así sucesivamente. El último, pero no menos importante. La CLI de Prisma permite crear una migración. Hay dos comandos para la migración, el dev y el deploy. El dev se utiliza durante el modo de desarrollo. Entonces, si cambias el esquema, por ejemplo, y agregas una nueva columna o una nueva tabla, debes llamar al comando dev para crear la nueva migración. Las migraciones están dentro de la carpeta de Prisma, dentro de la carpeta de migraciones. Es una migración, está dentro de una carpeta única con la marca de tiempo y una descripción simple que puedes agregar, y la migración es un archivo simple. En este caso, solo hay una migración para crear la tabla de topping, la tabla de pizza, y así sucesivamente. Puedes usar el dev, pero también puedes usar el deploy. En mi caso, si ejecuto el deploy, intento aplicar la migración, pero la migración ya está aplicada, y en este caso, no sucede nada. Es común usar el deploy en tu CI o en el script de implementación, dependiendo de cómo implementes esto.

Ahora es el momento de pasar a la parte de GraphQL.

Entonces, en este caso, hay dos carpetas importantes para esta implementación. La primera es la carpeta GraphQL, donde puedes encontrar el antiguo archivo jql. Ese es el esquema que contiene todas las descripciones para tu servidor jql. En este caso, la mutación contiene todas las mutaciones. Cierra esto, está bien. La mutación contiene la mutación, la consulta contiene todas las consultas y la suscripción, todas las suscripciones. También puedes crear un archivo con todo el código dentro. Prefiero dividirlo porque es más claro que tener solo un archivo. Luego también puedes crear una carpeta con, no sé, la entrada para la pizza, el tipo de pizza, y así sucesivamente. Bastante simple si ya conoces GraphQL, y espero que ya lo conozcas. La operación se utiliza por Mercurius para crear nuestro caso de prueba, por ejemplo. Puedes crear la consulta para la bienvenida y Mercurius code gen convierte esta operación en un objeto que puedes usar para probar tu servidor durante el modo de desarrollo.

Ahora es el momento de ver el código. Entonces, en el código fuente, típicamente está el servidor. Como puedes notar, el servidor es un servidor Fastify simple. Debes inicializar una instancia simple de Fastify y luego puedes registrar algo. En este caso, el puerto es el 3000 y en la carpeta de la aplicación, en el archivo de la aplicación, puedes encontrar la aplicación real. La aplicación real tiene dos puntos principales. Primero, intenta cargar los complementos y los complementos en este caso son dos. La configuración, por lo que es bastante simple en este caso. Uso un TypeBox para verificar si el entorno del proceso contiene el node-ev y también la URL de la base de datos. Entonces, en este caso, estoy seguro de que el proceso contiene estas dos propiedades y estos dos entornos. Y luego la parte importante es el contexto de la base de datos. El contexto de la base de datos es un complemento simple de Fastify que se utiliza para inicializar el cliente de Prisma. En este caso, FP es la función del complemento de Fastify y puedes crear el cliente de Prisma de esta manera, por lo que puedes usar el nuevo cliente de Prisma y puedes pasar la URL en este caso, la URL se utiliza como cadena de conexión. Luego debes crear la conexión de esta manera y luego puedes decorar tu servidor utilizando la función de propiedad decorada y en este caso, el contexto de la base de datos contiene nuestra instancia de cliente de Prisma. De esta manera, puedes usar app.dbcontext para tener acceso a la implementación de Prisma. Por último, pero no menos importante, hay un gancho en el onClose para desconectar la conexión si el servidor se apaga. Bastante simple. Ahora es el momento de ver la parte importante para GraphQL.

GraphQL se registra como otro complemento en este caso, y en el archivo GraphQL puedes encontrar toda la implementación. Como puedes notar, Mercurius es un complemento simple registrado en Fastify y debes pasar alguna configuración. La primera es el esquema. Entonces, utilizando la función de carga de esquema, utilizo la biblioteca mercurius.code.gen para convertir la carpeta JQL en código real para Mercurius. Lo primero es el archivo de carga de esquema. Utilizando la sintaxis, puedes indicarle a mercurius.code.gen dónde puede encontrar el archivo JQL y la biblioteca, verifica, está bien. No es un buen día probablemente para mi Mac, está bien. Y el convertidor, todos los archivos en formato de esquema para Mercurius. Y también, si quieres, puedes habilitar el modo de observación para cambiar en tiempo real tu servidor. En este caso, para mí, solo está en modo de desarrollo. Y en este caso, cuando algo cambia, actualizo la parte de GraphQL para una nueva característica u algo así.

Bien, lo último antes de ir al código real es la función Code-Gen Mercurius que utiliza la idea del archivo JQL para convertir el archivo JQL a TypeScript. Entonces, en la ruta de destino como origen del generador de resolutores TS, puedes encontrar todas las definiciones de tu servidor. Puedes encontrar, por ejemplo, la mutación, la consulta y la mutación. Este tipo es utilizado por el desarrollador para asegurarse de que el servidor respete la definición JQL.

Ahora, si vuelvo a la parte de GraphQL, cuando configuras esto, solo tienes que prestar atención o cuidar de crear el código para tu negocio. Entonces, para crear el cargador y el resolutor. Hoy, solo hablaré sobre el resolutor porque solo tengo 20 minutos, pero es similar para el cargador. Dentro de la carpeta de resolutores, puedes encontrar el indexador. El resolutor es un objeto simple con tres propiedades, la consulta, la mutación y la suscripción. Y en mi caso, creo una carpeta simple para cada una de estas. Entonces, dentro de la consulta, la mutación, puedes encontrar todas las mutaciones para la pizza, para el topping y así sucesivamente. Dentro de la consulta, puedes encontrar todas las consultas para la pizza, el topping y así sucesivamente. Y bastante simple en este caso. Quiero mostrarte, por ejemplo, la mutación para crear una pizza. En este caso, la implementación es bastante simple. Entonces, utilizando esta sintaxis, la sintaxis típica de TypeScript, creo una nueva función llamada createPizza. Y utilizando el tipo de la mutación, le digo a esta función que debe respetar la firma de createPizza en los tipos de mutación. De esta manera, estoy seguro de que el código debe respetar el archivo JQL descrito anteriormente.

Entonces, la función es bastante simple. Así que está el padre. En este caso, no tienes que prestar mucha atención al padre. Ese es el primer parámetro. El segundo parámetro son los datos que llegan del cliente, en este caso, la pizza, el nombre y la lista de ingredientes. El tercer parámetro contiene el contexto de GraphQL, si quieres, la instancia de la aplicación Fastify, y también el objeto pubsub en este caso. Usando la aplicación, puedes obtener, por ejemplo, el registro, en este caso, Pino, o el DbContext. El DbContext, como puedes ver, es el cliente Prisma, registrado anteriormente con el complemento. Y de esta manera, puedes llamar, por ejemplo, a DbContext.pizza para insertar la pizza en tu base de datos. El DbContext es bastante simple de usar, así que puedes usar DbContext, y puedes tener la pizza, en nuestro caso, el topping y la receta, si quieres. Cada modelo crea un objeto con todos los posibles métodos para insertar, seleccionar, actualizar y eliminar.

Luego puedes juntar las cosas, y puedes crear tu lógica de negocio, en este caso. ¿Qué es PubSub? Si tienes alguna suscripción, puedes usar el objeto PubSub para notificar que algo ha sucedido. En este caso, creo el evento de creación de pizza, en este caso, y esto notifica la suscripción. Y si algo está suscrito, recibe la notificación, bastante simple.

La consulta es muy similar, así que te muestro, por ejemplo, el ingrediente. En este caso, uso el objeto query, y utilizando el getTopping, en este caso, tienes diferentes objetos, porque en este caso, la consulta quiere la paginación. Puedes obtener el límite y el desplazamiento, y puedes usar el método find para encontrar los muchos ingredientes en este caso, o también puedes obtener usando el getTopping para obtener el ingrediente por un ID, por ejemplo. Sé que el ejemplo es bastante simple, pero probablemente has entendido el beneficio de usar esta architecture.

Desde la demo, creo que eso es todo, así que quiero volver a la diapositiva nuevamente para cerrar la charla, así que... Perfecto. De acuerdo. En conclusión, no soy un vendedor, así que no estoy aquí para vender esta solución, pero es una posible solución si quieres trabajar con GraphQL. ¿Por qué decidimos seguir este camino? Primero, Fastify y Mercurio son una buena opción para crear un servidor GraphQL. Fastify es muy rápido si quieres, y Mercurio también. Y la combinación te ayuda a crear un servidor muy performance. Sí, si conoces GraphQL, puedes cometer un error muy grave si quieres. Pero en este caso, no está en el lado de Mercurio, sino en el lado del desarrollador, probablemente el problema. Usando Prisma, puedes crear una capa entre tu aplicación y la database. Puedes tener una buena developer experience. Sí, tienes que crear, tienes que hacer un intercambio porque ir directamente a la database o usar NRM en este caso. Pero con Prisma, típicamente puedes mejorar la velocidad de tu equipo. Y si tienes algún problema con la consulta, es muy fácil personalizar la consulta y crear tu propia consulta si quieres. Por último pero no menos importante, los desarrolladores se centran en crear características para tu negocio y no pierden tiempo resolviendo problemas de framework porque hay un parche, un parche que rompe tu servidor. Y ambos aman TypeScript.

Así que creo que eso es todo. Si quieres, aquí puedes encontrar la diapositiva y también la demo. Solo comparto mis redes sociales allí entonces. Si quieres, sumérgete en Prisma. Escribí una serie de Prisma y puedes encontrarla en dev.io o en este código QR. Y eso es todo.

Muchas gracias a todos. Estos son mis contactos. LinkedIn y Twitter están abiertos, así que son bienvenidos si desean charlar conmigo. Si desean suscribirse a mi canal de YouTube, este es el nombre. Y si desean leer algo, dev.io o mis publicaciones en el blog están en mi blog. Y eso es todo. Gracias. Espero que hayan disfrutado de este contenido y gracias a todos y a Node Congress. Gracias, Luca. Increíble.

Y ya tenemos varias preguntas. Bueno, la primera, creo que ya ha sido respondida parcialmente, no es la que he seleccionado ahora mismo. Un segundo. ¿Está disponible en algún lugar el código de la demo? ¿Está en el mismo código QR? Sí, podemos volver al código. Tienen que ir a este código QR. Es el código de GitHub, el enlace de GitHub, y tienen que hacer un fork o clonarlo y ejecutar el servidor. No está disponible en un enlace, pero pueden descargarlo, clonar el proyecto y ejecutarlo. Así que espero que esté bien. Sí, gracias por eso. Sí. Siguiente pregunta. ¿Recomendarías usar Mercurius para las conexiones de web socket de las suscripciones de GraphQL? ¿Cómo lo compararías con GraphQL Apollo? Bueno, en realidad, las suscripciones de GraphQL, ¿cuál estás usando? En realidad, las suscripciones de GraphQL utilizan un web socket de forma predeterminada. Así que si deseas construir otro web socket para manejarlo, puedes hacerlo sin ningún problema. Pero de forma predeterminada, en GraphQL, puedes usar las suscripciones de GraphQL con un web socket. Muy simple. ¿Cómo se compara con GraphQL Apollo? Bueno, en el último período, he perdido el control de Apollo probablemente.

Lo probé hace dos años. El problema con Apollo es que está basado en Express. Ahora sé que han creado su propio servidor. Probablemente sea mejor en este momento. Pero si quieres, también puedes integrar Apollo en Fastify sin ningún problema. Hay un complemento. Gracias, Matteo.

En realidad, no me gusta comparar dos cosas. Hay pros y contras en la solución. Por lo general, tienes que encontrar la mejor manera para tu solución probablemente. Muy bien. Gracias. ¿Alguna opinión sobre Apotos, GraphQL, que cambia la generación del esquema para que sea TypeScript primero? No sé qué es Apotos GraphQL en realidad. Así que probablemente no tengo la respuesta en este caso. Por favor, danos más información. Sí, otra pregunta. ¿Por qué Mercurios? Esta es una buena pregunta. En realidad, como dije antes, ya conocemos Fastify y Mercurios, en este caso, está construido sobre Fastify. La otra motivación es el amor del equipo por Fastify, y nos cambiamos de Express a Fastify. La forma de crear una API REST de Node antes con Fastify es similar a Express, pero tienes un buen rendimiento, un buen mantenimiento. Gracias, Matteo. Además, puedes tener nuevas versiones. Si revisas las versiones de Express, se detuvo en la versión cuatro, tres, no recuerdo, cuatro, tres o cuatro. Lo siento, ocho años. Sí, la comunidad detrás es mejor en este momento que otros frameworks para el entorno de Node.

Un recordatorio rápido para todos. Oh, sí. Sí. Un recordatorio rápido también. También, ten cuidado de crear muchos cargadores que crean muchas consultas y que generan mucho tiempo de espera para tus usuarios probablemente. Genial.

Sí, creo que solo tengo una pregunta rápida que puede ser muy rápida. Entonces, si pudieras elegir tu stack ideal para digamos database más API en sí, limitemos a Node.js. ¿Qué elegirías? Solo limítalo a Node.js. Probablemente para la API REST y Graphql Fastify. Y para la database, si tienes que elegir NORM, elige Prisma. Si conoces muy bien, si tienes tiempo y conoces muy bien el proveedor, utiliza el proveedor por defecto para tu proveedor. Así que utiliza el proveedor MongoDB y así sucesivamente. Por lo general, si quieres, si quieres controlar tu database, utiliza directamente el proveedor expuesto por la database, en este caso, porque te da más control del personal. Gracias, Luca. Gracias. Sí. De acuerdo. Sí. De acuerdo. Gracias. Gracias. Gracias. Gracias. Gracias. Gracias. Gracias. Gracias. Gracias. Gracias.