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

Rate this content
Bookmark

¿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.

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.

Available in English

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

From GraphQL Zero to GraphQL Hero with RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Local State and Server Cache: Finding a Balance
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
Batteries Included Reimagined - The Revival of GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Batteries Included Reimagined - The Revival of GraphQL Yoga
The Guild has recently released Envelop - a new, modern GraphQL Server Framework and plugin system. In this talk I’ll share a brief overview of Envelop and why you should probably upgrade your existing GraphQL server to it.
Rock Solid React and GraphQL Apps for People in a Hurry
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Rock Solid React and GraphQL Apps for People in a Hurry
In this talk, we'll look at some of the modern options for building a full-stack React and GraphQL app with strong conventions and how this can be of enormous benefit to you and your team. We'll focus specifically on RedwoodJS, a full stack React framework that is often called 'Ruby on Rails for React'.
Step aside resolvers: a new approach to GraphQL execution
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.

Workshops on related topic

Build with SvelteKit and GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Scott Spence
Scott Spence
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
End-To-End Type Safety with React, GraphQL & Prisma
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
Sabin Adams
Sabin Adams
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL for React Developers
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
Roy Derks
Roy Derks
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
Build a Headless WordPress App with Next.js and WPGraphQL
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
Kellen Mace
Kellen Mace
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
Relational Database Modeling for GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
WorkshopFree
Adron Hall
Adron Hall
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
Building GraphQL APIs on top of Ethereum with The Graph
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
Nader Dabit
Nader Dabit
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.