The video on-demand of this session is available to logged in QCon attendees only. Please login to your QCon account to watch the session.

Session + Live Q&A

GraphQL Caching on the Edge

In January 2018, I was the CTO of a fast-growing startup with a very ready-heavy use case. Our infrastructure couldn't keep up with our load, so our servers were crashing almost daily. At the time, no traditional CDN could cache GraphQL APIs, meaning we had no choice but to build our own solution.

It turned out that GraphQL is an ideal framework for edge caching. Let's peel back the curtains and look into why and how to edge cache production GraphQL APIs at scale.

Main Takeaways

1 Find out how GraphCDN does GraphQL request caching in 60 datacenters worldwide.

2 Learn how to do GraphQL caching at scale.


What is the work that you are doing today?

I am working on a Graph CDN, which is a GraphQL gateway that helps you to operate your GraphQL API in production. What that exactly means for us is we provide edge caching for our customers, analytics, error tracking, alerts. Essentially, we are building all of the tooling that usually very big companies build internally, we're building it so that everyone can get access to that tool. Not just the very big companies that have entire teams dedicated to this topic. We want to help anyone to operate their GraphQL API in production at any scale.

How does GraphQL edge caching look like?

We are based on Fastly's Compute@Edge product, so we have Fastly's 60 worldwide data centers and customers pass all of their GraphQL requests through our gateway. And so a user that is, for example, in Vienna, in Austria, like I am, will hit their local data center first before being passed on to the origin to complete the request. But the first time the user requests that data, it goes through to the origin and the data is fetched and then cached at the edge locally in Vienna. And so the next time the user from Vienna, Austria, requests the same data rather than going all the way to the origin instead, the edge cache in Vienna can handle that request immediately and return that cache data to the user, making for a lightning fast user experience and also taking a bunch of load off of your origins plate. Our customers usually report that they cache anywhere between 60 up to 99% of their GraphQL requests and the reliability implications of this are huge because most obviously we handle traffic spikes for people. We have customers that get huge traffic spikes because they launched a new product or because a sport game is on. All of that traffic spike is basically invisible to the origin because the data is just immediately cached and returned from the edge cache to all the users without having to hit the origin over and over and over and over again.

What are the goals for your talk and what do you want people to walk away with from the talk?

Most people that I speak to about what we're doing and what we're working on are surprised that both this doesn't exist yet, but also that it is possible and I want to really provide a deep look into how this GraphQL edge caching actually works and how could you implement it yourself, right? What does it actually mean to build GraphQL edge caching? For many people surprisingly GraphQL is ideal for caching because it is introspectable, because it has that strict schema and because it differentiates between crazy mutations, which actually means all these attributes of GraphQL mean that it's actually ideal for caching. You can build standardized tooling that caches GraphQL queries pretty well. In fact, that's kind of what GraphQL clients do. If you think about Apollo clients or Oracle or Relay, all of these GraphQL clients, they all are essentially GraphQL caches, and each caching is kind of the same thing with slightly different constraints, but it's the same fundamental logic, and I want to dive into that, dive into how GraphQL clients cache, but also how edge caches cache GraphQL requests.

Who's the audience for the talk?

There will be a lot of technical details for developers, and hopefully, they'll have a deeper understanding of how GraphQL caching works. But at the same time, it's a lot about showing that this is even possible and actually a lot more possible than people think. It seems very finicky and hard and difficult to do, but actually, it is definitely possible. It is not easy, but it is thanks to GraphQL unique properties definitely something that more people should be taking advantage of. And I hope that architects and managers can take that away from the talk and say that actually, this is something we should probably investigate, either built internally or rely on an external service to handle for them.

Can you give us one example of what's not easy? Just a teaser for your talk?

One of the main things that you want to do is invalidate cached data. Imagine if a mutation passes through Graph and that's called editBlogpost. As soon as that mutation completes from the origin, the Gateway can analyze that response and see the blog post has changed, and it needs to invalidate any cached queries that contain that specific blogpost in the 60 worldwide datacenters that we have. That's one of the more tricky pieces, right? How do you understand what is being changed and then invalidate that data globally all around the world in these edge locations? That's one of the trickiest problems to solve that usually, people who don't do caching don't have to deal with. Stuff like that is really what I want to get into and show how it is doable. You can do this and it's possible and feasible, actually.


Speaker

Max Stoiber

Co-Founder @GraphCDN

Max is the co-founder of GraphCDN, the GraphQL CDN. Previously, he worked at Gatsby, and before that GitHub, who acquired his last startup. He's most widely known for creating open source projects used by millions of developers, including styled-components and react-boilerplate.

Read more
Find Max Stoiber at:

Date

Monday Nov 8 / 12:10PM EST (40 minutes)

Track

Living on the Edge

Topics

GraphQLEdge ComputingDevopsCachingClustering & Caching

Add to Calendar

Add to calendar

Share

From the same track

Session + Live Q&A Edge Computing

Building Modern Transportation System with KubeEdge, How We Made It

Monday Nov 8 / 11:10AM EST

Transportation is one of the most important industries of edge computing, building a highly distributed, edge-cloud collaborative platform to leverage new applications and services for modern transportation has been a hot topic these years.To deal with massive edge apps & nodes deployment,...

Kevin Wang

Lead of Cloud Native Open Source Team @Huawei

Huan Wei

Chief Architect at HarmonyCloud

Session + Live Q&A Edge Computing

Machine Learning at the Edge

Monday Nov 8 / 01:10PM EST

Traditional machine learning pipelines and methods break down in supporting machine learning at the edge; however, the data we get via embedded systems and edge devices is valuable to solve many problems. Rather than taking the traditional approach, we can utilize new distributed data science and...

Katharine Jarmul

Security & Privacy in Machine Learning

PANEL DISCUSSION + Live Q&A Edge Computing

Architecting for the Edge

Monday Nov 8 / 02:10PM EST

Whether edge means CDN servers, cell towers or user devices, embracing the Edge in applications and services requires different architecture building blocks. We are going to have a discussion on main differences in how one should design and build services when embracing the Edge as part of the...

Jason Shepherd

VP of Ecosystem at ZEDEDA

Max Stoiber

Co-Founder @GraphCDN

Kaladhar Voruganti

Senior Fellow, CTO Office @Equinix

View full Schedule