GraphQL Caching Desmitificado

Rate this content
Bookmark

¿Cómo implementarías una caché GraphQL de alto rendimiento? ¿Cómo podemos diseñar un buen algoritmo para ello? ¿Existe una solución de código abierto eficiente, escalable y fácil de implementar? ¿Cómo se calcula la clave de caché? ¿Qué hay de las invalidaciones de caché? ¿Sería posible deduplicar la ejecución del resolvedor? Esto puede parecer desalentador, pero en realidad todo se reduce a código y algoritmos.

En esta charla vamos a explorar un sistema de caché GraphQL que hemos desarrollado para Mercurius, uno de los servidores GraphQL más rápidos para Node.js.

21 min
10 Dec, 2021

Video Summary and Transcription

La charla de hoy se centra en la caché de GraphQL y en mejorar el rendimiento utilizando Fastify y Mercurius. El experimento involucra servicios federados, caché de resolvedores y pruebas de carga con AutoCANON. Habilitar la caché con un TTL de 0 segundos puede aumentar el rendimiento en 4 veces. El módulo AsyncCacheDedupe permite una caché eficiente y evita cálculos innecesarios. La canalización de Redis ha mejorado las solicitudes por segundo en 100 veces. La invalidación de caché es un tema en desarrollo.

Available in English

1. Introducción a la Caché de GraphQL

Short description:

Hoy, Matteo Collina hablará sobre la caché de GraphQL y cómo mejorar el rendimiento de tu puerta de enlace de GraphQL en cuatro veces. Utilizará Fastify, uno de los frameworks web más rápidos para Node.js, y Mercurius, el adaptador de GraphQL que se ejecuta sobre Fastify e integra con la biblioteca GraphQL JIT para una ejecución de consultas más rápida.

Hola a todos. Soy Matteo Collina y hoy voy a hablarles sobre la caché de GraphQL. Antes de comenzar, síganme en Twitter en matteocollina. Pueden encontrarlo en la diapositiva, así que aquí estoy. Hablo mucho sobre Node.js, JavaScript, GraphQL, código abierto, todas las cosas, así que no sé, puede que les resulte interesante. Hoy vamos a hablar sobre GraphQL, pero antes de comenzar, oh, una cosa más. Sigan mi boletín, Aventuras en Node-Land, node-land.dev. ¿Quién soy? Soy Matteo, formo parte del Comité Técnico de Dirección de Node.js, y soy Arquitecto de Software Principal en una empresa llamada NearForm. Échennos un vistazo, estamos contratando, haciendo mucho por GraphQL, así que si quieren, es una buena empresa. De todos modos, yendo un poco más lejos, cuando era niño en los años 90, sí, les estoy diciendo cuántos años tengo, estaba realmente, realmente, realmente impresionado por este espectáculo de David Copperfield, y no sé acerca de ustedes, pero siempre quise ser, me fascinaba la magia, ¿verdad? Entonces, y, ya saben, cómo hacer que las cosas desaparezcan, cómo hacer que las cosas, ya saben, vuelen, lo que sea. Es muy, muy interesante y me parecían muy entretenidos los espectáculos. Y de hecho, hay mucho trabajo duro detrás de la magia, ¿verdad? Así que en esta charla, vamos a hablar de magia y vamos a hacer que las cosas desaparezcan. De hecho, vamos a aplicar magia a GraphQL. Así que vamos a mostrar cómo mejorar el rendimiento de tu puerta de enlace de GraphQL en cuatro veces. ¿Cómo? Haciendo que las cosas desaparezcan.

Entonces, ¿cómo? Bueno, hablemos un poco sobre la herramienta del oficio. Necesitamos herramientas, ¿verdad? Necesitamos cosas que vamos a usar para esta pequeña demostración. Así que primero, vamos a usar Fastify. Fastify es uno de los frameworks web más rápidos para Node.js. Es muy fácil de usar. Es similar a Express, pero más moderno, más rápido. Tiene más características. ¡Todas las cosas que necesitarás. Es genial! Échale un vistazo. Vamos a usar Mercurius. Mercurius es el adaptador de GraphQL que puedes ejecutar sobre Fastify. Es genial. Mercurius ofrece algunas características interesantes que lo hacen único. En primer lugar, se integra con la biblioteca GraphQL JIT, para que podamos tomar tu consulta y hacer una compilación en tiempo real para tu consulta,

2. Herramientas, Experimento y Magia

Short description:

Las herramientas discutidas incluyen una biblioteca llamada AutoCANON para pruebas de carga en JavaScript. El experimento involucra dos servicios federados por una puerta de enlace, que ofrecen objetos de usuario y publicación. Se utilizará el compilador en tiempo real y el módulo de caché para habilitar la caché del resolvedor. El servicio es un objeto de usuario simple con un ID y un nombre. Se realizarán pruebas de carga en vivo en hardware dedicado.

para que pueda ejecutarse mucho más rápido. Y así sucesivamente. También hace algunas cosas más como esa para rendimiento y razones de velocidad. Es genial. Así que échale un vistazo. Oh, también admite la federación completa, tanto como puerta de enlace como microservicio. Entonces, la última herramienta del oficio es una biblioteca llamada AutoCANON. AutoCANON es una herramienta que escribí hace mucho tiempo para realizar algunas pruebas de carga. Y puedes usar esto para omitir cosas en JavaScript. Así que es para omitir pruebas de carga en JavaScript. Es genial. Lo uso muchas veces. Estas son nuestras herramientas, ¿verdad? De acuerdo. Entonces vamos a usar estas. Tres cosas. Así que hablemos un poco sobre nuestro experimento. Tenemos dos servicios que están federados por una puerta de enlace. Y uno ofrece el objeto de usuario, y el otro ofrece el objeto de publicación. Y vamos a utilizar el compilador en tiempo real, y habilitaremos la caché para el resolvedor dependiendo de nuestros algoritmos. Así que podemos realizar múltiples experimentos, ¿verdad? Puedes verlo aquí. Puedes realizar múltiples experimentos. Y ver el impacto de este módulo de caché, ¿cómo se ve este módulo? Así que veamos dónde desaparecen o reaparecen las cosas.

¿Cuál es el servicio? Bueno, este es un ejemplo del servicio. Literalmente, es un objeto de usuario que tiene un ID y un nombre. Muy simple, ¿de acuerdo? No hay nada especial aquí.

Así que es hora de hacer un poco de magia. ¿Están listos para la magia? Hagamos que las cosas desaparezcan. ¿Cómo? Bueno, volvamos a nuestra terminal. Así que está conectado a mi servidor. Es

3. Mercurius Cache Repo and Experiments

Short description:

En el repositorio de caché de Mercurius, tenemos pruebas de referencia, servicios de puerta de enlace para datos de usuario y publicaciones, y experimentos utilizando AutoCanon. Ejecutar el script sin caché realiza 3000 solicitudes por segundo. Con un TTL de cero segundos, aumenta 4 veces. Exploremos esto más a fondo.

en hardware dedicado. Así que voy a realizar pruebas de carga en vivo. ¡Oh, wow! Así que veamos mi repositorio de caché de. Todo esto está en el repositorio de caché de Mercurius. Y podemos ver que tenemos nuestras pruebas de referencia y esta es la puerta de enlace que acabo de mostrarte. Y tenemos nuestros servicios de puerta de enlace. Este es el de usuario y este es el de publicaciones. Ten en cuenta que estos servicios sirven todos losdata desde la memoria. Por lo tanto, no hay bases de datos involucradas. Son realmente rápidos. Y este es nuestro banco de pruebas. Entonces, ¿cómo evaluamos el rendimiento de las cosas utilizando AutoCanon? Básicamente, requerimos AutoCanon. Y luego tenemos nuestra consulta, y enviamos nuestra consulta como cuerpo con 100 conexiones concurrentes. Eso es todo. Y luego hacemos varios experimentos utilizando nuestro script de banco de pruebas. Entonces, en nuestro script de banco de pruebas, puedes ver que estamos ejecutando todos los servicios más varias cosas. Varios ejemplos, uno sin caché, uno con un tiempo de vida de cero segundos y uno con un tiempo de vida de un segundo y uno con un tiempo de vida de 10 segundos. Así que vamos a ejecutar este script. Primero que nada, este es nuestro básico, este es nuestro control, ¿verdad? Es un modo de puerta de enlace. Algo donde no vamos a cachear nada. Así que hemos hecho esto, ¡y vaya! Realiza 3000 solicitudes por segundo. Bueno, parece rápido o no, depende de lo que quieras hacer. La latencia es buena, sin embargo. Así que estoy bastante contento con los resultados. Ahora, con un TTL de cero segundos, ¡vaya! ¿Cómo? Simplemente se multiplicó por 4. No estoy haciendo ninguna caché. Es un tiempo de vida de cero segundos. Simplemente lo activo y se multiplica por 4. Y, ¡vaya! Todavía 4 veces. ¿Cómo es esto posible? ¿Cómo funciona esto?

4. Caching and Deduplication

Short description:

Nuestro punto de referencia tiene una latencia P99 de 80 milisegundos, lo que resulta en aproximadamente 3000 solicitudes por segundo. Al habilitar la caché con un tiempo de vida de 0 segundos, podemos reducir la latencia a 18 milisegundos y aumentar el número de registros por segundo y el rendimiento en 4 veces. El gráfico de llamas muestra que la mayor parte del tiempo se dedica ahora a la caché, gracias a la deduplicación. El diagrama del bucle de eventos de Node.js proporciona información sobre el flujo de ejecución y el tiempo de bloqueo entre C++ y JavaScript, que se utiliza para la deduplicación mediante el cálculo de una clave de caché.

OK, dejemos esto ejecutándose. Explicaremos esto en un momento. Entonces, nuestro punto de referencia tiene una latencia P99. Eso es lo que quieres medir para una latencia de 80 milisegundos. Mientras que una solicitud por segundo te da más o menos 3000 solicitudes por segundo.

Sin embargo, también puedo crear gráficos de llamas. ¿Qué es un gráfico de llamas? Bueno, es una representación de dónde se está gastando nuestro tiempo de CPU. Más específicamente, todo ese tiempo se está gastando en hacer solicitudes HTTP. Por cierto, si no has visto mis charlas sobre undici y Node.js, por favor échales un vistazo porque puedes acelerar bastante tus llamadas HTTP.

Pero el resultado es que la gran mayoría del tiempo se gasta haciendo HTTP. Entonces, bueno, ¿qué podemos hacer? Necesitamos reducir el HTTP. Sí, ¿cómo podemos mejorar esto? Bueno, simplemente haciéndolo un tiempo de vida de caché de 0 segundos, podemos reducir la latencia a 18 milisegundos y multiplicar por 4 el número de registros por segundo y el rendimiento. ¡Vaya! Esto es una gran mejora sin tener ninguna caché en absoluto. Cero caché. No es caché en absoluto. Simplemente habilitamos la caché. Bueno, y si habilitamos la caché, no mejora mucho. Bueno, ¿cómo es posible? Bueno, este es el gráfico de llamas de nuestra puerta de enlace ahora. Y como puedes ver en el medio, la solicitud HTTP que estaba allí antes ha desaparecido. Y ahora tenemos en el medio un gran bloque de tiempo que se gasta haciendo la caché, vale. Literalmente, ahora la parte inferior es el sistema de caché. Entonces, ¿pero a dónde fue la llamada HTTP? ¿Dónde desapareció? Bueno, lo que estamos haciendo, estamos haciendo deduplicación, que es la estrategia clara que hará las cosas increíblemente más rápidas, especialmente en el lado gráfico. Así que volvamos y hablemos un poco sobre el bucle de eventos de Node.js. Probablemente hayas visto este diagrama sobre Node. Esto es genial porque has visto que la solicitud llega y sabes que tienes un evento, va a la cola de eventos, se procesa, y luego esto genera más actividad asíncrona. Lo que no has visto es este diagrama. Este diagrama es una presentación diferente del mismo bucle de eventos exacto. Sin embargo, lo muestra desde el punto de vista de la función JavaScript que se está ejecutando. Entonces, cuando el bucle de eventos está en ejecución, está esperando algo, está esperando, ¿verdad? Esto es, a la izquierda y a la derecha, el bucle de eventos está esperando. Luego, cuando ocurre un evento, llama a C++, llama a JavaScript, que normalmente programa algún next-tick o algunas promesas, luego vuelve a C++, que a su vez inicia las promesas y la ejecución de next-tick, y finalmente, una vez que todo eso se ha hecho y se ha resuelto, vuelve y cede el control al evento. Todo el tiempo que lleva entre medias, desde este punto de inicio del C++ hasta el final, es el tiempo en el que el bucle de eventos está bloqueado. Entonces, para hacer la deduplicación de la solicitud, lo que estamos haciendo es, cuando estamos recibiendo nuestra función de resolución, podemos calcular una clave de caché, ¿vale? Y con esa caché

5. Módulo AsyncCacheDedupe

Short description:

El módulo AsyncCacheDedupe te permite calcular la misma clave de caché para un resolvedor y evitar ejecutarlo varias veces. Automáticamente almacena en caché los resultados y proporciona una forma rápida y eficiente de evitar cálculos innecesarios.

clave, podemos crear una promesa coincidente. Entonces, y luego podemos, ya sabes, completar nuestra ejecución, ¿verdad? Sin embargo, cuando llega una ejecución de seguimiento, podemos calcular exactamente la misma clave de caché y obtener la promesa que colocamos allí antes, que aún puede estar pendiente. Sin embargo, no necesitamos ejecutar el mismo resolvedor dos veces. Solo podemos ejecutarlos una vez, ¿verdad? Es bastante genial. Podemos evitar muchos cálculos de esta manera. Esto es lo que hace este módulo. Se llama AsyncCacheDedupe. Creas una nueva caché donde defines algunos métodos en ella y que son asíncronos, y luego automáticamente almacena en caché los resultados. Y podemos tener, puedes tener un TTL, pero automáticamente deduplica y almacena en caché el resultado. Es fenomenal y es muy rápido. Entonces puedes usar esto en todos los demás lugares donde quieras usar el sistema, ¿verdad? Bueno, en primer lugar, pero la pregunta ahora es ¿cómo podemos calcular una buena clave de caché? Porque queremos, para usar este módulo, necesitamos proporcionar una clave de caché y ¿qué es una buena, cómo podemos

6. Implementación de Resolvedores y Caché

Short description:

Al implementar un resolvedor en Node.js, puedes usar cuatro argumentos: root, arguments, context e info. Al combinar la anatomía del resolvedor, el objeto info y otros parámetros, puedes calcular una clave de caché para cada resolvedor de GraphQL. Sin embargo, las cachés en proceso son problemáticas y el uso de Redis como una caché compartida entre nodos puede generar problemas de rendimiento.

¿Cómo obtenemos una buena clave de caché? Bueno, veamos la anatomía de nuestro resolvedor. Cuando implementas un resolvedor en Node.js, puedes tener cuatro argumentos. Tienes el root, tienes los argumentos, tienes el contexto, que es el objeto actual, pero luego tienes los argumentos para el resolvedor, el contexto que puede incluir tu solicitud de Node.js, respuesta, conexiones de base de datos, todas las cosas, y luego el objeto info que incluye la definición de la consulta que estás calculando. Bueno, ten eso en mente y espera un segundo. Ahora, lo que puedes hacer es tomar un objeto arbitrario y convertirlo en JSON, ¿verdad? Puedes llamar a JSON.stringify. Si haces eso, dependiendo del orden de las propiedades, obtendrás diferentes JSON. Sin embargo, hay un módulo llamado save-stable-stringify, que independientemente del orden de las propiedades, siempre generará el mismo JSON. Entonces, lo que podemos hacer es usar este módulo y combinarlo con la anatomía del resolvedor, el info, los datos en el objeto info, el root y todas esas cosas para crear una clave de caché, un hash para un hash arbitrario para ese resolvedor específico.

¿Cómo se implementa esto? Bueno, como puedes ver aquí, es bastante simple. Navegamos por el objeto info para obtener la selección, la selección actual del campo, y luego creamos un objeto que incluye el objeto resuelto actual, los argumentos, los campos y algunos parámetros más. Es genial, ¿ves? Podemos calcular una clave de caché para cada resolvedor de GraphQL. Esto es lo que llamamos TTL de cero segundos. Estamos deduplicando todos los resolvedores que acceden a tus datos. Agregar caché no mejora mucho aquí porque los servicios objetivo son en su mayoría muy simples. No requieren mucho tráfico. Lo siento. No requieren muchas CPUs para calcular. No tienen una base de datos. No tienen nada. Sin embargo, agregar más caché cambiará en caso de que necesites más. Agregar más tiempo aquí mejorará tu rendimiento si los servicios objetivo no son lo suficientemente rápidos o son lentos o algo así. Bueno, todo esto es muy bueno, ¿verdad? Pero las cachés en proceso son problemáticas. Entonces, realmente no podemos aumentar demasiado el tiempo porque todo está en proceso, ¿verdad? Si todo está en proceso, si los datos expiran en mi nodo, no están expirando en el otro nodo. Entonces, ¿cómo podemos implementar eso? Bueno, una de las buenas soluciones es usar algo como Redis para implementar un estado compartido, una caché compartida, entre todos los nodos. Sí, pero lo intentamos y lo implementamos, y no funcionó. Y no funcionó, principalmente porque, ya sabes, en nuestra prueba de referencia, teníamos cien consultas gráficas por segundo, cada una de las cuales invocaba 20 resolvedores. Y esto implica que, ya sabes, si quieres obtener esos datos de la caché, son de doscientos a dos mil Gets de Redis por segundo. Y desafortunadamente, el tiempo de ida y vuelta de Redis es de 0.5 milisegundos.

7. Redis Pipelining y Rendimiento

Short description:

Hemos resuelto el problema del bloqueo sin conexión de cabeza con el auto-pipelining, una técnica que agrupa múltiples comandos en un solo pipeline de Redis, reduciendo el tiempo de ida y vuelta de la red. Esta lógica en producción ha mejorado las solicitudes por segundo en 100 veces y ha ampliado Redis en 15 veces. Redis maneja el tráfico sin problemas. Sin embargo, nombrar cosas e invalidaciones de caché siguen siendo desafíos.

Pero el tiempo real de ida y vuelta es de 15. Así que no se puede hacer mucho. Necesitamos paralelizar estos Gets de Redis, ¿verdad? Entonces, tal vez puedas usar un grupo de conexiones o, no sé. Bueno, hay algo mejor. Bueno, en realidad ya he resuelto este problema. Sí, es con esta figura. De todos modos, echa un vistazo a esta charla que di en RedisConf 2021. Explico cómo resolver el problema del bloqueo sin conexión de cabeza con el auto-pipelining. Entonces, básicamente, es una técnica que hemos inventado para... Bueno, hemos aplicado al cliente de Redis que permite agrupar múltiples comandos que ocurren en la misma iteración del bucle de eventos en un solo pipeline de Redis. De modo que los enviamos como un lote, asegurándonos de reducir el tiempo de ida y vuelta de la red en el servidor. Es genial, y funciona maravillosamente, y puedes realmente acelerar el acceso a Redis. Pero esto es en realidad lo mismo que hacíamos antes con el sincronismo. Así que, es tortugas todo el camino hacia abajo. Días felices.

Así que, tenemos toda esta lógica en producción. Es importante decir que este código en producción nos está dando una mejora de 100 veces en términos de número de solicitudes por segundo. Y tiene un factor de expansión de 15 veces en Redis. Así que, para cada consulta compleja que recibimos en promedio, estamos haciendo 15 Gets de Redis con diferentes claves de caché para verificar si las cosas funcionan como nos gustaría. Es bastante genial, ¿verdad? Pero también es bastante aterrador. Por cierto, Redis ni siquiera parpadea un ojo, ni siquiera parpadea un ojo. Está perfectamente bien con todo este tráfico, así que no nos importa. Redis es increíble, por cierto. Usa Redis. Más Redis para todos.

Así que, eso es lo que tenemos en la vida real. Esta técnica ha sido un salvavidas fenomenal recientemente. Pudimos manejar un pico enorme de tráfico sin siquiera parpadear. Así que, sí, échale un vistazo. Es genial. Sin embargo, hay dos cosas en la ciencia de la computación, ¿verdad?

8. Invalidación de Caché y Conclusión

Short description:

No hemos discutido la invalidación de caché, pero es un tema fundamental. Aunque se me ha acabado el tiempo, estamos trabajando activamente en la implementación de este módulo. Pronto podrás invalidar la caché localmente y en Redis. Mantente atento a las actualizaciones en Twitter y en mi boletín. ¡Gracias por ver!

Uno es nombrar cosas, y el otro es la invalidación de caché. Oh, vamos, está realmente mal, ¿verdad? Porque no hemos hablado de cómo invalidamos la caché, y este es uno de los temas fundamentales. Sin embargo, casi hemos llegado a los 20 minutos, así que se me ha acabado el tiempo. Así que, no los voy a cubrir en esta charla. Estoy bromeando. No hemos terminado de trabajar. No hemos terminado la implementación de este módulo. Pero en realidad estamos trabajando en esto. Así que, en realidad, los añadiremos a AsyncCache.JDube pronto. Por lo tanto, podrás invalidar la caché tanto localmente como en Redis más temprano que tarde. Así que, échale un vistazo, porque estaremos atentos a mis noticias en Twitter y en mi boletín, porque habrá algunos buenos anuncios en las próximas semanas. Con eso, solo quería decirte gracias. Como dije, soy Matteo Collina. Soy el Arquitecto Principal de Software en NearForm. Puedes encontrarme en Twitter, en Matteo Collina. Por favor, hazme cualquier pregunta que quieras en Twitter, y estaré muy feliz de responder tan pronto como pueda. Así que gracias por ver esta charla. ¡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

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!
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.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
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
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
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 Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
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.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
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.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
WorkshopFree
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
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate