Power Up your GraphQL Apps with CDNs

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Slides
Rate this content

If you have some GraphQL data that you think would benefit from CDN caching at the edge, it’s actually really simple to get everything working well. This talk will walk you through the interplay between several tools: * Automatic Persisted Queries with Apollo Link lets queries use GET while mutations still use POST * Apollo Cache Control lets you specify cache control information in a fine-grained, schema oriented way * Apollo Engine generates small query IDs you can use in those GET requests to limit the cache key size, and sets the Cache-Control header for the CDN Then, when we put it all together, you can see those results getting cached in your favorite CDN service, tada!!

This talk has been presented at React Day Berlin 2022, check out the latest edition of this React Conference.

FAQ

HTTP caching involves two main concepts: freshness and validation. Freshness determines how long a browser can keep a resource, while validation checks if the client needs to fetch the resource again from the server.

A CDN (Content Delivery Network) caches content like images, videos, and webpages on proxy servers located closer to end users, allowing faster and seamless content delivery.

Yes, GraphQL can use HTTP caching mechanisms by setting cache control headers on GraphQL queries. However, since GraphQL typically uses POST requests, persistent queries can be used to enable caching.

Persistent queries allow GraphQL queries to be sent over HTTP GET instead of POST, enabling CDNs to cache the responses. This is achieved by using ApolloLink and Apollo's automatic persistent queries feature.

Apollo cache control allows specifying cache control information at different levels of specificity within a GraphQL schema. This enables fine-grained control over the caching behavior of different pieces of data.

Apollo Engine generates smaller query IDs for use in GET requests and combines cache control hints into a single header that CDNs can understand, facilitating efficient caching of GraphQL data.

Caching improves the performance and speed of GraphQL queries by storing and reusing responses, reducing the need for repeated data fetching from the server.

HTTP GET requests are used for data retrieval and can be cached by CDNs, while POST requests are typically used for data modifications and are not cached by default. Persistent queries help use GET for GraphQL queries.

You can implement caching for GraphQL queries using Apollo by setting up ApolloLink persistent queries, using Apollo cache control hints, and leveraging Apollo Engine to generate query IDs and cache control headers.

Using CDNs for GraphQL apps improves query performance, reduces server load, and enhances user experience by delivering cached content quickly from servers closer to the end users.

Naz Delam
Naz Delam
13 min
05 Dec, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk discusses how to grow GraphQL apps with CDNs by exploring concepts like caching, freshness, and validation. It explains how CDNs cache content closer to end users, improving delivery speed. The use of persistent queries and cache control headers in GraphQL is explored as a solution to caching challenges. The talk also highlights the interplay between automatic persistent queries, Apollo cache control, and Apollo Engine for efficient CDN caching.

1. Introduction

Short description:

How to grow your GraphQL apps with CDNs. Enable and caching, two words that don't really go well together. Let's give you a little bit of intro about me. My name is Naz. I am currently an engineering manager working at LinkedIn.

How to grow your GraphQL apps with CDNs. Faster GraphQL queries with caching and CDNs. This is what we're going to talk about today. Enable and caching, two words that don't really go well together. It's been a lot of talks in the community, how are we going to enable caching and GraphQL queries together? Well, before we jump into that, let's give you a little bit of intro about me. My name is Naz. I am currently an engineering manager working at LinkedIn. Before LinkedIn, I worked as an engineering manager and individual contributor at Netflix. I'm currently running JavaScript Weekly with a group of amazing individuals on Twitter spaces and also hosting career QAs on LinkedIn events. I'm also a career coach and a mentor on Mentor Cruise, mentoring and coaching a lot of engineers across the globe. If you want to learn more about me, visit my website, naz.dev.

2. Caching and CDNs

Short description:

So, let's talk about caching. HTTP caching has two main concepts: freshness and validation. Freshness determines how long a resource can be kept in the cache, while validation checks if the resource needs to be refetched. Last modified and ETAC headers are used for validation. CDNs are content delivery networks that cache content closer to end users, delivering it more quickly.

So, let's talk about caching. Before we learn about GraphQL and caching, let's talk about HTTP caching. What is HTTP caching and how it's done. HTTP caching has two main concepts. One is freshness and two is validation.

Freshness means, as a browser, how long can I keep this resource in my cache. Freshness is a way for server to give a resource to client and then instruct the client on how long it can keep a resource. In practice, this is done through the HTTP header cache control. Cache control max age equals 60 means the browser can keep the resource for 60 seconds and then start for re-requesting the resource to the server again.

But we come to validation. Validation means when that 60 seconds is done, if the client decides to re-request the resource again from the server, it will ask the server, hey server, do I really need to refetch this again? So there is a way for the server to actually know if the client really needs the resource again or does it have the latest and updated and valid resource. So if nothing has changed on that resource, there is not really a need for the server to re-send the resource back to the client. And this is actually done through last modified in ETAC headers on server side. Last modified is a date and a time and ETAC is a token that indicates the state of the resource. For example, if not matched, the ETAC.

These are very important headers, but can GraphQL really actually use any of these mechanisms? Why are we saying they don't go together? They are super and we can just attach it to HTTP headers. Well, we'll see. Before we dig into that, let's talk about CDNs a little bit. If you're not familiar with what a CDN is, a CDN is a content delivery network, which caches content like images, videos, webpages, anything that is in proxy servers that are located closest to the end users than the original servers.

A proxy server is a server that receives requests from clients and passes them along to the servers. Because the servers are closer to the clients who are making the request, a CDN is able to deliver the content more quickly and seamlessly to the clients. Let's explain this easier. We can think of CDN as being a chain of grocery stores. Instead of just having one grocery store, one walmart, which is the main branch of walmart that all the houses in the area or all the people go to that walmart branch because that's the only branch to shop. We can have small branches of walmart at every neighborhood. So instead of people need to go to the main branch to pick up their stuff. They can actually look for stuff in the smaller branch first. And if that thing that they want to shop exists in that smaller branch. Awesome. They can pick it from there.

3. CDN Caching and Persistent Queries

Short description:

CDNs cache static content on proxy servers at the edge of the network, saving copies of requested content. GraphQL queries can have cache control headers, but attaching them to POST requests is challenging. Persistent queries provide a solution by using GET requests and shortened query IDs. This brings GraphQL closer to regular HTTP GET requests. Another option is poll cache control, where a cache control header is returned from a specific REST API endpoint.

It's way faster and very quicker. If not, they can go to the major branch or the main branch and then also ask the branch to have those things in the smaller or pricier branches so they can get it from there. This is how CDNs caching work. It's basically replicating the static content on proxy servers at the edge of the network. So when a user requests content from a website using a CDN, the CDN fetches the content from the origin server or the main server and then saves a copy of the content for future requests. Cached content remains on the CDN cache as long as users continue to request it.

Well, what about GraphQL queries? Like where are we going with this? Well, CDNs know how to cache resources when they actually have those request headers we talked about attached to them. But can we use those request headers with GraphQL queries? Yes, we can. We can set cache control headers on a GraphQL query, right? Well, except we usually use resources that are query documents. Well, still a resource. So we can set headers. In the example that you see here, one document is our resource here and we could undoubtedly attach the cache control last modified and some e-text headers to it. But even though that is possible in theory since GraphQL uses post, but in action we basically can't attach those headers to post and you need to use get. So that's why we come to persistent queries as solution number one to go around attaching those headers we talked about to GraphQL queries.

A central principle in REST that we talked about is that you use a URL to identify a piece of data, a piece of resource, and then we use get gets verb in our HTTP request to indicate that you're doing some data read, not a write. That tells our CDNs it's OK to catch that result since it's not expecting to modify something on the back end. In contrast to that, historically, most graphical tools sent HTTP requests using posts. Instead of a URL, they used a complicated request body that contains a query and variables. As an added complication, in some browsers, there is relatively a small URL size limit. That means you can fit the entire query that you're making and also the valuables in the get requests. So what can we do? Well, persistent queries come to our rescue. By combining ApolloLink, our modular network interface for the client, and Apollo's engine automatic persistent queries feature, we can address both concerns at once. After setting up the engine, you can easily add ApolloLink persistent queries to your client code. So here is a code example of using a persistent query link. This will do two things for us. First, sending queries over HTTP GET instead of POSTs, right, because CDNs need that GET request to understand that resources are not changing, while still using POST for mutations. And second, use a shortened persisted query ID in the GET URL so that the cache key for CDNs is shorter and we don't hit the URL size limits. This brings GraphQL much closer to the regular HTTP GET requests that CDNs are designed to handle.

Well, what else can we do than persistent queries? Let's talk about poll cache control. What's that? With our REST API, we can simply return a cache control header from a specific endpoint.

4. Cache Control and CDN Caching

Short description:

With GraphQL, we constantly improve queries on the front end, adding and moving fields as needed. Poll cache control ensures cache hints stay up to date with query changes over time. It allows specifying cache expiration at different levels while maintaining front-end query flexibility. The engine combines cache hints into a cache control header understood by CDNs. Cache control can also be used with Apollo Engine 2 for caching without a CDN. This talk highlighted the interplay between automatic persistence queries, Apollo cache control, and Apollo Engine for efficient CDN caching.

Just like we talked about, until we write a new endpoint, it will remain the same, right? But with GraphQL, we'll constantly be improving queries on the front end. You're adding fields and moving fields. You have different versions of the UI needed. So how do you make sure your cache control hint stays up to date with the shape of the query, even as the data included in the result changes over time? That's what a poll cache control is designed to solve.

This is a spec for how the GraphQL server should return cache hints on a per-field level. So here we can see that comes with a reference implementation for JavaScript that kind of shows us how we could specify cache hints with different levels of specificity. So here we do have the cache hints, max age of 5 seconds for the whole schema set with the cache control. Or we could have that set on a graphical type or field, as we did here. Or even we can set that on a single execution of a resolver. It doesn't need to be on the whole schema. This is super important because it allows our API to specify the expiration of different pieces of data. We don't want everything to expire at the same level. While maintaining the freedom of the front-end code to specify whatever queries it needs. Well, cache control.

At the end of the day, the engine combines all these hints into one convenient cache control header. That's our winner that our CDN can understand. Just a note here. If you're not using a CDN, you can use cache control to power the caching feature of Apollo Engine 2, so you don't have to specifically use a CDN. So, to wrap everything up we talked about today, if you have some graphical data that you think you would benefit from a CDN caching at the edge, it's actually really simple to get everything working well. This is a great example of how interplay between several tools we've been working on for a while. First, automatic persistence queries with Apollo. Link lets queries use GET while mutation still use POST. Second, Apollo cache control lets you specify cache control information in a fine-grained schema-oriented way. And third, Apollo Engine generates the smaller query IDs, so we can use those queries IDs in our GET requests without hitting the cache key size. And set the cache control header for the CDN. I hope you really enjoyed this talk. If you have any questions again, or if you want to connect with me, feel free to find all my handles at mass.dev. And I'm looking forward to chat with you all on the Discord channel of the conference.

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
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.
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
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.
Batteries Included Reimagined - The Revival of GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Batteries Included Reimagined - The Revival of 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.
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
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.
Adopting GraphQL in an Enterprise
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
Adopting GraphQL in an Enterprise
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.
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
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

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
Workshop
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.
Build with SvelteKit and GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Workshop
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
Relational Database Modeling for GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
Workshop
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
Build and Deploy a Backend With Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
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
Workshop
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.
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.