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

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

¿Estás cansado de luchar con las limitaciones de las API REST? "Rompiendo las Cadenas de REST: Un Camino de Fastify y Mercurius hacia la Gloria de GraphQL" es tu guía hacia un mejor camino.

Descubre cómo GraphQL resuelve las deficiencias de REST y cómo implementarlo usando Fastify y Mercurius. Cubriremos:


1. Las limitaciones de REST que frenan las aplicaciones modernas.

2. Las características revolucionarias de GraphQL.

3. Pasos para hacer la transición usando Fastify y Mercurius.


Desbloquea todo el potencial de tus APIs y libérate de las restricciones de REST. Únete a nosotros para aprender, adaptarte y elevar tu juego de API.

This talk has been presented at Node Congress 2024, check out the latest edition of this JavaScript Conference.

Luca Del Puppo
Luca Del Puppo
23 min
04 Apr, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
GraphQL es un lenguaje de consulta versátil que permite la creación de un único servidor y API que puede servir diferentes tipos de dispositivos. Mercurius es un adaptador de GraphQL de alto rendimiento construido sobre Fastify, que ofrece características como caché, compilación en tiempo real y soporte para suscripciones y federación. La charla demuestra cómo construir un servidor GraphQL usando Mercurius Fastify y TypeScript, incluyendo la configuración del servidor, el esquema, los resolvedores y los cargadores. Destaca los beneficios de usar GraphQL con TypeScript y cómo los cargadores pueden optimizar las consultas al reducir el número de llamadas a la base de datos. La conclusión enfatiza los beneficios de construir un servidor GraphQL con Mercurius y proporciona recursos adicionales para una exploración más profunda.

1. Introducción a GraphQL y sus ventajas

Short description:

Hola, y bienvenidos a esta charla sobre cómo construir un servidor GraphQL utilizando Fastify y Mercurius. GraphQL es un lenguaje de consulta que te permite crear un tipo de servidor que sirve diferentes tipos de dispositivos. Te permite utilizar solo un servidor y crear solo una API para servir diferentes tipos de dispositivos como escritorio, móvil, reloj inteligente, etc. GraphQL contiene un esquema donde puedes definir consultas, mutaciones y suscripciones. Las consultas recuperan datos, las mutaciones actualizan datos y las suscripciones te permiten suscribirte a eventos.

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.

2. Usando Mercurius con GraphQL

Short description:

Y tal vez puedas actualizar la interfaz de usuario en tu aplicación. Puedes usar GraphQL para fusionar microservicios y escalar tu servidor fácilmente. Mercurius es un adaptador de GraphQL de alto rendimiento construido sobre Fastify. Tiene muchas características principales y complementos e implementa las especificaciones de Apollo Federation. Mercurius es de código abierto y tiene licencia MITA. Permite el almacenamiento en caché, evita el problema N plus, utiliza la compilación en tiempo real, admite suscripciones y federación, y permite consultas por lotes y persistencia de consultas.

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.

3. Construyendo un Servidor GraphQL con Mercurius Fastify

Short description:

Hoy te mostré cómo construir un servidor GraphQL utilizando Mercurius Fastify y TypeScript, resolver el problema N plus, crear una aplicación Fastify, registrar el servidor y comenzar el servidor en localhost:3000. También demostré cómo configurar Mercurius para la parte de GraphQL, importar y registrar Mercurius, y pasar el esquema, los resolvers, los loaders y habilitar la interfaz de usuario de GraphQL para realizar pruebas.

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.

4. Esquema, Consultas, Mutaciones y Resolvers

Short description:

El esquema contiene el tipo para categoría y publicación, junto con una entrada para crear una nueva publicación. Las consultas expuestas incluyen getCategory, getPost y getPostByCategory, con paginación para evitar problemas de rendimiento. Existen mutaciones para crear categorías y publicaciones. El resolver implementa el esquema.

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.

5. Consultas, Mutaciones y Loaders

Short description:

El objeto de consulta contiene todas las consultas descritas en el esquema, incluyendo getCategory y obtener una sola categoría por ID. Se pueden generar definiciones de TypeScript a partir del esquema, lo que proporciona seguridad de tipos para los argumentos. La paginación y las mutaciones funcionan de manera similar, con argumentos para insertar y devolver datos. Los loaders permiten cargar relaciones entre tipos. La aplicación se puede ejecutar y probar utilizando GraphiQL, con consultas para obtener categorías y publicaciones, y mutaciones para crear categorías y publicaciones. Se pueden generar definiciones de TypeScript utilizando el complemento Mercurius Code Gen.

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.

6. GraphQL con TypeScript y Resolver vs Loader

Short description:

Puedes usar GraphQL con TypeScript y tener una única fuente del esquema. El resolver o el loader se pueden utilizar para cargar las dependencias entre tipos. Utilizando el loader, puedes optimizar las consultas y reducir el número de llamadas a la base de datos. El loader realiza una única consulta para recuperar todos los datos necesarios.

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.

7. Conclusion and Additional Resources

Short description:

No odies las API REST, son increíbles, pero en algunos escenarios no son la mejor solución. Construir un servidor GraphQL utilizando Mercurius es pan comido y ofrece los mismos beneficios que Fastify. Ten cuidado con el diseño de tu aplicación para entender su comportamiento. Considera cuidadosamente qué expones a los desarrolladores frontend y agrega monitoreo para rastrear la actividad de tu aplicación. Aquí tienes algunos recursos para explorar: la documentación de Fastify y Mercurius, los blogs de NearForm y backend cafe, los canales de YouTube de NearForm y Adventure in Nordland, y un libro recomendado sobre Fastify.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

De GraphQL Zero a GraphQL Hero con RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
De GraphQL Zero a GraphQL Hero con RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Vue.js London Live 2021Vue.js London Live 2021
24 min
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Top Content
This Talk discusses handling local state in software development, particularly when dealing with asynchronous behavior and API requests. It explores the challenges of managing global state and the need for actions when handling server data. The Talk also highlights the issue of fetching data not in Vuex and the challenges of keeping data up-to-date in Vuex. It mentions alternative tools like Apollo Client and React Query for handling local state. The Talk concludes with a discussion on GitLab going public and the celebration that followed.
Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
Aplicaciones sólidas de React y GraphQL para personas con prisa
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Aplicaciones sólidas de React y GraphQL para personas con prisa
The Talk discusses the challenges and advancements in using GraphQL and React together. It introduces RedwoodJS, a framework that simplifies frontend-backend integration and provides features like code generation, scaffolding, and authentication. The Talk demonstrates how to set up a Redwood project, generate layouts and models, and perform CRUD operations. Redwood automates many GraphQL parts and provides an easy way for developers to get started with GraphQL. It also highlights the benefits of Redwood and suggests checking out RedwoodJS.com for more information.
Adoptando GraphQL en una Empresa
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
Adoptando GraphQL en una Empresa
Today's Talk is about adopting GraphQL in an enterprise. It discusses the challenges of using REST APIs and the benefits of GraphQL. The Talk explores different approaches to adopting GraphQL, including coexistence with REST APIs. It emphasizes the power of GraphQL and provides tips for successful adoption. Overall, the Talk highlights the advantages of GraphQL in terms of efficiency, collaboration, and control over APIs.
Deja paso a los resolvers: un nuevo enfoque para la ejecución de GraphQL
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Deja paso a los resolvers: un nuevo enfoque para la ejecución de GraphQL
GraphQL has made a huge impact in the way we build client applications, websites, and mobile apps. Despite the dominance of resolvers, the GraphQL specification does not mandate their use. Introducing Graphast, a new project that compiles GraphQL operations into execution and output plans, providing advanced optimizations. In GraphFast, instead of resolvers, we have plan resolvers that deal with future data. Graphfast plan resolvers are short and efficient, supporting all features of modern GraphQL.

Workshops on related topic

Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
React Summit 2022React Summit 2022
173 min
Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
Top Content
Workshop
Kellen Mace
Kellen Mace
En esta masterclass, aprenderás cómo construir una aplicación Next.js que utiliza Apollo Client para obtener datos de un backend de WordPress sin cabeza y usarlo para renderizar las páginas de tu aplicación. Aprenderás cuándo debes considerar una arquitectura de WordPress sin cabeza, cómo convertir un backend de WordPress en un servidor GraphQL, cómo componer consultas usando el IDE GraphiQL, cómo colocar fragmentos GraphQL con tus componentes, y más.
Construir con SvelteKit y GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Construir con SvelteKit y GraphQL
Top Content
Workshop
Scott Spence
Scott Spence
¿Alguna vez has pensado en construir algo que no requiera mucho código de plantilla con un tamaño de paquete pequeño? En esta masterclass, Scott Spence irá desde el hola mundo hasta cubrir el enrutamiento y el uso de endpoints en SvelteKit. Configurarás una API de GraphQL en el backend y luego usarás consultas de GraphQL con SvelteKit para mostrar los datos de la API de GraphQL. Construirás un proyecto rápido y seguro que utiliza las características de SvelteKit, y luego lo desplegarás como un sitio completamente estático. Este curso es para los curiosos de Svelte que no han tenido una experiencia extensa con SvelteKit y quieren una comprensión más profunda de cómo usarlo en aplicaciones prácticas.

Tabla de contenidos:
- Inicio e introducción a Svelte
- Inicializar el proyecto frontend
- Recorrido por el proyecto esqueleto de SvelteKit
- Configurar el proyecto backend
- Consultar datos con GraphQL
- Recuperación de datos en el frontend con GraphQL
- Estilización
- Directivas de Svelte
- Enrutamiento en SvelteKit
- Endpoints en SvelteKit
- Despliegue en Netlify
- Navegación
- Mutaciones en GraphCMS
- Envío de mutaciones GraphQL a través de SvelteKit
- Preguntas y respuestas
Modelado de Bases de Datos Relacionales para GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Modelado de Bases de Datos Relacionales para GraphQL
Top Content
Workshop
Adron Hall
Adron Hall
En esta masterclass profundizaremos en el modelado de datos. Comenzaremos con una discusión sobre varios tipos de bases de datos y cómo se mapean a GraphQL. Una vez que se haya establecido esa base, el enfoque se desplazará a tipos específicos de bases de datos y cómo construir modelos de datos que funcionen mejor para GraphQL en varios escenarios.
Índice de contenidosParte 1 - Hora 1      a. Modelado de Datos de Bases de Datos Relacionales      b. Comparando Bases de Datos Relacionales y NoSQL      c. GraphQL con la Base de Datos en menteParte 2 - Hora 2      a. Diseño de Modelos de Datos Relacionales      b. Relación, Construcción de Tablas Multijoin      c. Complejidades de Consulta de Modelado de Datos Relacionales y GraphQL
Prerrequisitos      a. Herramienta de modelado de datos. El formador utilizará dbdiagram      b. Postgres, aunque no es necesario instalar esto localmente, ya que estaré utilizando una imagen de Dicker de Postgres, de Docker Hub para todos los ejemplos      c. Hasura
Construir y Desplegar un Backend Con Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Construir y Desplegar un Backend Con Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic te permite desarrollar rápidamente GraphQL y REST APIs con un esfuerzo mínimo. La mejor parte es que también te permite desatar todo el potencial de Node.js y Fastify siempre que lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y plugins adicionales. En la masterclass, cubriremos tanto nuestros módulos de Open Source como nuestra oferta en la Nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). 
En esta masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la Platformatic Cloud.
Construyendo APIs GraphQL sobre Ethereum con The Graph
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Construyendo APIs GraphQL sobre Ethereum con The Graph
Workshop
Nader Dabit
Nader Dabit
The Graph es un protocolo de indexación para consultar redes como Ethereum, IPFS y otras blockchains. Cualquiera puede construir y publicar APIs abiertas, llamadas subgrafos, para hacer que los datos sean fácilmente accesibles.

En este masterclass aprenderás cómo construir un subgrafo que indexa datos de blockchain de NFT del contrato inteligente Foundation. Desplegaremos la API y aprenderemos cómo realizar consultas para recuperar datos utilizando diferentes tipos de patrones de acceso a datos, implementando filtros y ordenamiento.

Al final del masterclass, deberías entender cómo construir y desplegar APIs de alto rendimiento en The Graph para indexar datos de cualquier contrato inteligente desplegado en Ethereum.
Problemas difíciles de GraphQL en Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Problemas difíciles de GraphQL en Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
En Shopify a gran escala, resolvemos algunos problemas bastante difíciles. En este masterclass, cinco oradores diferentes describirán algunos de los desafíos que hemos enfrentado y cómo los hemos superado.

Tabla de contenidos:
1 - El infame problema "N+1": Jonathan Baker - Vamos a hablar sobre qué es, por qué es un problema y cómo Shopify lo maneja a gran escala en varios APIs de GraphQL.
2 - Contextualizando APIs de GraphQL: Alex Ackerman - Cómo y por qué decidimos usar directivas. Compartiré qué son las directivas, qué directivas están disponibles de forma predeterminada y cómo crear directivas personalizadas.
3 - Consultas de GraphQL más rápidas para clientes móviles: Theo Ben Hassen - A medida que tu aplicación móvil crece, también lo harán tus consultas de GraphQL. En esta charla, repasaré diversas estrategias para hacer que tus consultas sean más rápidas y efectivas.
4 - Construyendo el producto del futuro hoy: Greg MacWilliam - Cómo Shopify adopta las características futuras en el código actual.
5 - Gestión efectiva de APIs grandes: Rebecca Friedman - Tenemos miles de desarrolladores en Shopify. Veamos cómo estamos asegurando la calidad y consistencia de nuestras APIs de GraphQL con tantos colaboradores.