Manejo de Cambios Rompedores en GraphQL

Rate this content
Bookmark
Slides

Los requisitos cambian, pero los contratos de API son para siempre - ¡Ojalá! Un cambio rompedor es algo que no es compatible con versiones anteriores. Esto significa que un consumidor de tu API no podrá utilizar la nueva versión sin realizar un cambio en su código. Evitamos los cambios rompedores si es posible, pero hay casos en los que son inevitables. Podría ser algo pequeño: como hacer que un campo obligatorio sea opcional. O podría ser algo grande: como eliminar una consulta o una mutación. En esta charla revisaremos los tipos de cambios rompedores que puedes encontrar y cómo lidiar con ellos de manera elegante.

22 min
08 Dec, 2022

Video Summary and Transcription

Esta charla discute el manejo de cambios rompedores en un esquema de GraphQL, incluyendo el uso de la directiva deprecated para etiquetar campos que ya no deben ser utilizados. También cubre el proceso de implementación de APIs de GraphQL y aplicaciones móviles, destacando los desafíos de la adopción de versiones de aplicaciones móviles. La charla enfatiza la importancia de realizar actualizaciones seguras en aplicaciones móviles y proporciona estrategias para detectar y manejar cambios rompedores, como el uso de TypeScript y GraphQL Inspector. En general, la charla enfatiza la necesidad de minimizar el impacto en los usuarios al introducir cambios rompedores en esquemas de GraphQL.

Available in English

1. Introducción a los Cambios Rompedores en el Esquema de GraphQL

Short description:

Hola a todos, en esta parte hablaré sobre cómo manejar los cambios rompedores en un esquema de GraphQL. Explicaré qué es un cambio rompedor y proporcionaré un ejemplo de código para ilustrarlo. ¡Empecemos!

Hola a todos, es un placer estar aquí y es un placer hablar sobre algo que es muy relevante para mi trabajo, que es cómo manejar los cambios rompedores en un esquema de GraphQL.

Así que, una breve introducción sobre mí. Mi nombre es Kadi Kraman, actualmente soy el Director de Desarrollo Móvil en Formidable. Si no han oído hablar de nosotros, Formidable es una consultoría. Construimos sitios web, aplicaciones móviles, y por supuesto, APIs de GraphQL. En mis cinco años en esta empresa, creo que casi todos los proyectos tenían una API de GraphQL en ellos. Así que hemos estado haciendo esto bastante. En 2002, mi primera API de GraphQL fue alrededor de 2017, y desde entonces, he trabajado tanto en aplicaciones pequeñas como grandes, y principalmente como consumidor de API.

Como construyo muchas aplicaciones móviles, generalmente he sido el cliente de una API de GraphQL. Pasaría tal vez el 20 por ciento de mi tiempo escribiendo GraphQL, y el 80 por ciento de mi tiempo usando APIs de GraphQL. Así que, los cambios rompedores son algo muy relevante para mí porque soy el cliente que se ve afectado si ocurren cambios rompedores.

Entonces, ¿qué es un cambio rompedor? Un cambio rompedor en un esquema de GraphQL es básicamente una actualización que causa que el contrato de la API cambie de una manera que no es compatible con versiones anteriores. Ahora, ¿qué significa esto realmente? Voy a mostrarte usando un ejemplo de código. Así que, aquí tenemos un pequeño esquema. Tenemos una consulta donde puedes consultar un usuario por su ID y te devolverá un tipo de usuario. Y el tipo de usuario tiene solo el ID y el nombre en él. Ambos son campos obligatorios. Y si miramos cómo se vería una consulta. Así que, aquí a la derecha, vamos a consultar el usuario por ID, consultar el ID y el nombre, y obtenemos exactamente esos datos de vuelta. Entonces, digamos que tenías este tipo de usuario en tu proyecto actual y el cliente vuelve y te dice, oye, no queremos tener nuestro nombre como una cadena única. Queremos tener el nombre y el apellido por separado. Entonces, como un nuevo requisito, necesitas separar el campo de nombre en nombre y apellido. ¿Cómo lo harías? Serías tentado a hacer algo como esto. Así que, aquí hemos añadido el nombre y el apellido, que son ambas cadenas obligatorias. Pero luego, porque realmente no usamos el campo de nombre, podemos eliminar el campo de nombre. Ahora, esto parece estar bien desde el lado del esquema, desde el lado de la API. Cuando miramos desde el lado del cliente y consultamos la misma consulta que hicimos antes, nos encontramos con un error. Y el error dice no se puede consultar el campo nombre en el tipo usuario. Y de hecho, el campo de nombre ya no existe. Ahora, este es un ejemplo de un cambio rompedor.

2. Manejo de Cambios Rompedores en el Esquema de GraphQL

Short description:

Un cambio que no es compatible con versiones anteriores. En lugar de eliminar el campo, podemos agregar una notificación de deprecación usando la directiva deprecated. La directiva deprecated te permite etiquetar un campo en un esquema como un campo deprecado para comunicar a tus consumidores que este campo ya no debe ser utilizado. Forma parte de la especificación de GraphQL y la mayoría de los servidores de GraphQL deberían implementarla. Insomnia, un cliente de GraphQL, proporciona un ejemplo de cómo se muestran los campos deprecados en el esquema. Ahora te mostraré una forma de introducir un cambio rompedor en una API de GraphQL de manera relativamente segura siguiendo los pasos: agregar, deprecar, migrar, eliminar.

Un cambio que no es compatible con versiones anteriores. Porque una consulta que funcionaba en la versión anterior de esta API ya no funciona debido a este cambio. Veamos cómo haríamos este cambio compatible con versiones anteriores. En realidad, es sorprendentemente simple. En lugar de eliminar el campo, podemos agregar una notificación de deprecación usando la directiva deprecated. Aquí has visto que junto al campo de nombre, he agregado deprecated y también proporcioné una razón. Entonces, en este caso, está deprecado a favor de nombre y apellido.

Y aquí podemos ver que la consulta anterior que consultaba solo el ID y el nombre todavía funciona y la nueva consulta que consulta el nombre y el apellido todavía funciona. Por lo tanto, porque tanto la consulta anterior como la nueva funcionan, este es un cambio que es compatible con versiones anteriores. La directiva deprecated es realmente útil. Básicamente te permite etiquetar un campo en un esquema como un campo deprecado para comunicar a tus consumidores que este campo ya no debe ser utilizado. Forma parte de la especificación de GraphQL, lo que significa que la mayoría de los servidores de GraphQL deberían implementarla. La parte más importante, la mayoría de los IDE, herramientas y clientes de GraphQL que puedas estar utilizando detectarán esta notificación y te advertirán si estás utilizando un campo deprecado.

Aquí he agregado un ejemplo. Esto es de Insomnia, que es un cliente de GraphQL que utilizo para hacer consultas. Cuando veo el esquema y el tipo de usuario en particular, podemos ver que el campo de nombre ahora tiene un signo de exclamación junto a él. Si paso el cursor sobre él, me dice que el campo de nombre ahora está deprecado y también me muestra el mensaje de deprecación que escribí. Entonces está deprecado a favor de nombre y apellido. Ahora puede haber una razón, aunque rara vez, por la que simplemente tengas que introducir un cambio rompedor en la API. Voy a mostrarte una forma en la que podrías introducir un cambio rompedor en una API de GraphQL de manera relativamente segura. Las palabras clave que debes recordar son agregar, deprecar, migrar, eliminar. Desafortunadamente, no es un acrónimo muy bueno. Vamos a repasar cada uno de estos pasos para mostrarte qué significa cada uno. Este es nuestro estado inicial. Vamos a comenzar con este tipo de usuario que usamos antes, solo con el ID y un nombre. Y esta es nuestra pila de aplicaciones. Vamos a tener un sitio web, digamos que es una aplicación Xjs. Vamos a tener una API. Por supuesto, es una API de GraphQL. Y como construyo aplicaciones móviles, vamos a tener una aplicación React Native para iOS y Android en un tercer repositorio.

3. Despliegue de API GraphQL y Aplicaciones Móviles

Short description:

Los tres repositorios se despliegan por separado. La primera versión de web1, api1 y app1 implementan el tipo de usuario. Las etapas incluyen agregar campos al esquema, deprecar campos, lanzar una nueva versión de la API, migrar clientes y eliminar campos deprecados. El despliegue de aplicaciones móviles es más complejo, con diferentes versiones lanzadas en las tiendas y una transición gradual de usuarios.

Entonces, los tres están en repositorios separados y se despliegan por separado. Y la primera versión de estos web1, api1 y app1 implementan el tipo de usuario como se ve aquí.

Ahora, la primera etapa, agregar, es bastante sencilla. Vamos a agregar los campos del esquema que deben agregarse. En este caso, vamos a agregar el nombre y apellido al tipo de usuario.

La siguiente etapa, deprecar, generalmente se realiza junto con agregar. Pero en este caso, vamos a deprecar los campos que podríamos querer eliminar en el futuro. Aquí hemos agregado la directiva deprecated. Usamos la directiva deprecated para agregar una notificación de deprecación al campo de nombre en el tipo de usuario.

Ahora, cuando hayamos terminado con todos nuestros cambios, lanzaremos una nueva versión de la API GraphQL a api2. Ahora, api2 sigue siendo compatible con app1 y web1, lo que significa que este es un cambio compatible con versiones anteriores.

El siguiente paso es la migración. En esta etapa, debes actualizar todos los clientes, todo lo que esté utilizando tu API GraphQL, para que utilicen la nueva API. Luego iremos al sitio web y la aplicación. Realizaremos el cambio y publicaremos las nuevas versiones para asegurarnos de que todos nuestros usuarios las estén utilizando.

Ahora, cuando estés seguro de que nadie está utilizando web1 y app1, y hayas publicado web2 y app2, entonces podría ser seguro eliminar el campo. Aquí podemos eliminar el campo de nombre que fue deprecado del tipo de usuario y cuando hayamos terminado, desplegaremos la nueva versión de la API a api3. Ahora, api3 no es compatible con web1 y app1, aún recibirían un error, pero si nadie los está utilizando, ya has publicado el cambio y estarán utilizando web2 y app2, entonces esa es una eliminación aceptable.

Como desarrollo aplicaciones móviles, no sería un desarrollador de aplicaciones móviles si en este punto no me desviara y explicara por qué esto es mucho más difícil en aplicaciones móviles. A nivel más alto, así es como se ve el despliegue de sitios web y APIs. Has terminado tu versión 1, la vas a subir a donde la publiques, digamos AWS, estará disponible para los usuarios y el 100% de tus usuarios la utilizarán.

Ahora, cuando se trata de lanzar la v2, cuando termines de codificarla, la subirás a AWS, la pondrás disponible e instantáneamente todos tus usuarios cambiarán y el 100% de tus usuarios utilizarán la v2 y nadie utilizará la v1. Cuando termines la v3, la lanzarás, el 100% de tus usuarios cambiarán inmediatamente.

Ahora, esto parece bastante obvio, pero de hecho, no es así en absoluto para las aplicaciones móviles. Así es como se ve el despliegue de una aplicación móvil. Cuando hayamos terminado nuestra v1, la subiremos a las tiendas, obtendremos la aprobación y cuando la tengamos, la publicaremos en la App Store y Play Store. Y como es la primera versión de nuestra aplicación, el 100% de nuestros usuarios la utilizarán.

A continuación, cuando estemos listos para la v2, la lanzaremos en nuestras tiendas, la aprobaremos y la publicaremos en nuestras tiendas. Luego, tomará tiempo, así que nos iremos durante dos semanas, revisaremos las estadísticas después de dos semanas y veremos que tal vez el 60% de los usuarios la estén utilizando. Y el 40% de los usuarios aún están utilizando la v1.

4. Adopción de Lanzamiento de Aplicaciones Móviles

Short description:

Las aplicaciones móviles nunca alcanzan una adopción del 100% como lo hacen los sitios web. Las aplicaciones solo se actualizan si el usuario tiene las actualizaciones automáticas activadas o si actualizan manualmente desde la página de listado de la tienda. Puede haber un retraso significativo entre la publicación de la aplicación y que los usuarios realmente obtengan la actualización.

Y cuando hacemos otra versión, v3, la aprobamos, la lanzamos a las tiendas, nos vamos y volvemos después de dos semanas, descubriremos que tal vez el 65% de los usuarios la están utilizando. El 30% de los usuarios todavía están en v2 y el 5% de los usuarios todavía están en v1. Ahora, la triste verdad es que las aplicaciones móviles nunca alcanzan una adopción del 100% como lo hacen los sitios web. Y la razón de esto es que las aplicaciones solo se actualizan si el usuario tiene las actualizaciones automáticas activadas, o si van a la página de listado de la tienda y actualizan manualmente. Incluso si el usuario tiene las actualizaciones automáticas activadas, la actualización no sería instantánea, tan pronto como la aplicación esté disponible, se actualizará. En cambio, generalmente se actualizará una vez que conectes tu teléfono y lo conectes al Wi-Fi. Por lo tanto, puede haber un gran retraso entre la publicación de la aplicación y que los usuarios, incluso aquellos que están en primera fila, realmente la obtengan.

5. Realizando Actualizaciones Seguras en Aplicaciones Móviles

Short description:

Nunca es seguro realizar un cambio disruptivo en una aplicación móvil, pero existen formas de hacer la actualización lo más segura posible. Incluir una solicitud de actualización a prueba de fallos para los usuarios es un último recurso. Monitorear el uso de consultas y usuarios activos puede ayudar a evaluar el impacto del cambio disruptivo. Los cambios en la API son más significativos para las aplicaciones móviles que para los sitios web. Cambiar un campo obligatorio a opcional en un esquema de GraphQL es un cambio disruptivo. Esto se puede ver en un ejemplo de código utilizando TypeScript.

Sabiendo eso, es posible que te preguntes, ¿cuándo es seguro realizar un cambio disruptivo en la API si se utiliza en una aplicación móvil? Bueno, la verdad que no quieres escuchar es que en realidad nunca es seguro realizar un cambio disruptivo de ese tipo. Siempre afectarás a alguien, es imposible obtener el 100% de tus usuarios, incluso con tu última versión.

Pero, ¿qué pasa si realmente tengo que hacerlo? Bueno, existen formas de hacer esta actualización lo más segura posible. Por lo general, en las aplicaciones móviles, incluimos, como desarrolladores, una medida de seguridad adicional, que básicamente es una solicitud que le pide a los usuarios que actualicen si desean seguir utilizando la aplicación. Por lo general, la mayoría de las aplicaciones ya lo tienen incorporado, pero es un último recurso, no queremos usarlo, nunca debería ser parte de tu flujo de desarrollo normal porque es una experiencia de usuario terrible y los usuarios lo odian, y para ser honestos, a Apple tampoco le gusta, y no queremos molestar a Apple.

Mientras trabajaba en esta charla, una de las aplicaciones que uso regularmente tenía esta solicitud de actualización de la aplicación, así que la he agregado aquí como ejemplo. Básicamente, cuando abro la aplicación, inmediatamente recibo una alerta nativa que dice que esta versión está obsoleta, por favor ve a la tienda para actualizarla. Si presiono en `más información`, me llevará a la tienda de aplicaciones, donde me solicitará que actualice. He visto que han renovado por completo toda la aplicación. Creo que la reescribieron, por lo que presumiblemente, la versión anterior ya no es compatible. Ahora, incluso cuando llegas a este punto y has evitado que los usuarios utilicen la versión antigua de tu aplicación, técnicamente ni siquiera puedes estar seguro de que van a actualizar. Porque en este punto, puedo optar por no presionar el botón de actualización en la tienda de aplicaciones porque tal vez no estoy conectado a Wi-Fi y no quiero usar mis datos móviles. Y también puedo decidir que esto me molesta y voy a usar esta aplicación en el sitio web en su lugar, o simplemente no usarla en absoluto. Y una vez que hayas hecho todo lo posible para asegurarte de que los usuarios actualicen, solo necesitas monitorear que lo estén haciendo. Esto lo harás en dos niveles. Uno es en el lado de la API y otro en el lado de la aplicación. En el lado de la API, esto podría ser en AWS o en CoreLogix. Puedes generar métricas para monitorear el uso de consultas. Puedes generar una métrica para monitorear el uso de campos obsoletos y ver si se llaman o no. Y luego, en el otro lado, también puedes monitorear los usuarios activos de tus aplicaciones para cada versión de la aplicación para tener una idea del número de usuarios que aún utilizan versiones de la aplicación que están obsoletas y que tienen este cambio disruptivo y cuántos usuarios podrían verse afectados por este cambio disruptivo. Y una cosa a tener en cuenta es que los cambios disruptivos en la API son generalmente mucho más significativos para los usuarios y desarrolladores de aplicaciones móviles que para los usuarios y desarrolladores web. Porque en el sitio web, si tu sitio web se cae o no funciona, generalmente tus usuarios pueden tuitearte, pueden enviarte un correo electrónico a tu servicio de atención al cliente enojados, mientras que si una aplicación está rota, si la API no funciona, los usuarios tienen una forma muy agradable y conveniente de quejarse al respecto y lo harán en la página de listado de la tienda y te darán una calificación de una estrella debido a un cambio de una sola línea donde tu API no funcionó. Alejándonos de ese tema sombrío, juguemos un pequeño juego. ¿Cuál de estos es un cambio disruptivo? Tenemos el tipo de usuario con el ID y un nombre, y por un lado he hecho que el nombre pase de ser obligatorio a opcional, y por otro lado lo he hecho de opcional a obligatorio. ¿Viste el primero? En efecto, en un esquema de GraphQL, si tienes un campo que es obligatorio y luego lo cambias para que sea opcional, eso es un cambio disruptivo. ¿Y por qué es eso? Puede que no sea muy fácil verlo desde el esquema, pero será un poco más fácil verlo como un ejemplo de código. Aquí he utilizado TypeScript solo para que sea un poco más obvio. Y a la izquierda, tenemos un código que podrías tener en el frontend que utiliza esta API. Debido a que nuestro usuario solo tiene un ID y un nombre, podría tener una función de utilidad que utiliza el nombre y toma las primeras partes como el primer nombre. Ahora, después de haber realizado el cambio, hice que el nombre pasara de ser obligatorio a opcional.

6. Detectando y Manejando Cambios Disruptivos

Short description:

TypeScript ayuda a detectar valores nulos, que pueden causar errores en JavaScript. Cambiar el ID de usuario de obligatorio a opcional o viceversa es un cambio disruptivo. GraphQL Inspector es una herramienta útil para detectar cambios disruptivos en solicitudes de extracción. Compara los esquemas actuales y de la rama de trabajo, resaltando cualquier cambio. Eliminar tipos siempre es un cambio disruptivo. Agregar una etiqueta aprobada a una solicitud de extracción permite que CI pase incluso con un cambio disruptivo. Los cambios disruptivos en el esquema incluyen cambiar nombres, eliminar, cambiar tipos de datos y alterar requisitos de campo. Evita los cambios disruptivos, especialmente en aplicaciones móviles y de escritorio. Utiliza los pasos de agregar, deprecar, migrar, eliminar para minimizar el impacto en los usuarios. Echa un vistazo a GraphQL Inspector para mejorar tus flujos de trabajo de API de GraphQL.

Entonces, podría devolver nulo. De hecho, TypeScript me está ayudando y me dice que no puedo llamar a split en el nombre del usuario porque podría ser nulo. Y de hecho, si en algún momento el nombre del usuario devuelve nulo, obtendría un error de JavaScript al llamar a esta función.

Hagamos uno más. En este caso, tengo la consulta de usuario y estoy cambiando el ID de usuario por el que estoy consultando de obligatorio a opcional o de opcional a obligatorio. ¿Viste el segundo? Sí, el segundo cambio es disruptivo. Y puede ser confuso porque es lo opuesto para las entradas de consulta, porque aquí, cambiar el ID de usuario de opcional a obligatorio es disruptivo, no al revés. He utilizado las diferencias aquí a propósito para que puedas ver que como revisor es realmente fácil pasar por alto este tipo de cambios.

Afortunadamente, hay una herramienta que puede ayudarte. Si aún no lo has probado, definitivamente recomendaría echar un vistazo a GraphQL Inspector. Actualmente lo estamos utilizando en mi proyecto y ha marcado una gran diferencia. Hace muchas cosas, pero lo más importante para nosotros es que nos permite realizar una verificación en las solicitudes de extracción, lo que nos dirá si se introducirá un cambio disruptivo en la API. Puedes usar esto en cualquier tipo de CI. Nosotros usamos GitHub Actions, así que voy a mostrarlo como ejemplo. Aquí estamos configurando que va a comparar el esquema de GraphQL en el actual con el esquema de GraphQL en tu rama de trabajo actual. Así es como se ve en la solicitud de extracción real. A la izquierda, veremos un ejemplo de un cambio disruptivo, por lo que está configurado para que falle CI si hay un cambio disruptivo. Y puedes ver que se están eliminando los dos tipos. Eliminar tipos siempre es un cambio disruptivo y, por lo tanto, esto se resalta. Y lo otro interesante es que en el lado derecho, podemos ver algunos ejemplos de solo información. Estos no son errores ni advertencias, es solo información. Lo que hace GraphQL Inspector es resaltar cualquier cambio, por lo que esto llamará la atención del revisor sobre lo que realmente ha cambiado. Y esto es realmente importante porque debes ser muy consciente de lo que estás agregando a tu API de GraphQL, porque como puedes ver en el otro lado, eliminar cualquier cosa siempre es un cambio disruptivo. Una vez que lo agregas, eliminarlo podría ser un problema. Debido a que hemos habilitado el fallo en caso de cambio disruptivo, hay otra cosa que hemos agregado, que es tener una etiqueta aprobada. Puedes establecer tu propia etiqueta para un cambio disruptivo aprobado, puedes llamarnos como quieras, pero esta es nuestra etiqueta. Básicamente, si agregas esta etiqueta a una solicitud de extracción, incluso si tiene un cambio disruptivo, permitirá que CI pase. Y esto es realmente útil porque básicamente, cuando se introduce una solicitud de extracción, un revisor la revisará y se le resaltará que hay un cambio disruptivo y se debe tener una conversación sobre si este es un cambio que estamos dispuestos a aceptar, si hay otra forma de hacerlo y si se debe evitar por completo.

En resumen, hemos visto qué es un cambio disruptivo en el esquema. Esto incluye cambiar el nombre de un campo, eliminar un campo, cambiar el tipo de datos, hacer que un campo requerido sea opcional o hacer que una entrada opcional sea requerida. En general, debes evitar hacer cambios disruptivos tanto como sea posible, especialmente si tu API es utilizada por una aplicación móvil o cualquier tipo de aplicación de escritorio que no tenga el mismo flujo de publicación que los sitios web y las API. Pero si necesitas introducir un cambio disruptivo, puedes utilizar los pasos de agregar, deprecar, migrar, eliminar para minimizar la cantidad de usuarios que se verán afectados. Y finalmente, si aún no lo has hecho, te recomendaría mucho que eches un vistazo a GraphQL Inspector para mejorar tus flujos de trabajo de API de GraphQL. Muchas gracias, espero que hayas aprendido algo sobre los cambios disruptivos en GraphQL.

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.
React Day Berlin 2022React Day Berlin 2022
29 min
Get rid of your API schemas with tRPC
Do you know we can replace API schemas with a lightweight and type-safe library? With tRPC you can easily replace GraphQL or REST with inferred shapes without schemas or code generation. In this talk we will understand the benefit of tRPC and how apply it in a NextJs application. If you want reduce your project complexity you can't miss this talk.

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
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
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.