GraphQL Caching on the Edge

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.