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!!
Power Up your GraphQL Apps with CDNs
Transcription
you are graphical apps with cdns faster graphical queries with caching and cdns. This is what we're going to talk about today. graphical 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 jumped that let's give you a little bit of intro about me. My name is Nas. I am currently an engineering manager working at LinkedIn before LinkedIn. I worked as an engineer manager and individual contributor at Netflix. I'm currently running JavaScript weekly with a group of amazing individuals and tutor spaces and also hosting career's 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 as the dev 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 cash? Freshness is a way for server to give a resource to client and then instruct the client and how long it can keep a resource in practice. This is done through at the HTTP header cache control. So cash control max age equals 60 means the browser can keep the resource for 60 seconds and then start for read requesting your resource to the server again. But become too validation. Validation means when that 60 seconds is done. If the client decides to read 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 need 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 resend the resource back to the client. And this is actually done through last modified and etag headers on server side. Last modified is a date and a time and Intec is a token that indicates the state of the resource. For example, if not match. the etag These are very important headers, but can't graphical really actually use any of this mechanisms why we say they don't go together. These are super or 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 web pages. Anything is status in proxy servers that are located closest to the end users. Then 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 main to the clients who are making the requests a CDN is able to deliver the content more quickly and seamlessly to the clients. That's a little bit explain this easier. We can think of CDN as being a chain of grocery stores instead of just having one grocery store. Let's say one Walmart, which is the main branch of Walmart that all the houses in the area for 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 thinks that they want to shop existing very smaller Branch awesome. They can pick it from there. It's very 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 proxy branches so they can get it from there. This is how C dance caching board. It's basically replicating the static content on process servers at the edge of the network. So when a user requests content from a website using a CDN the CDN features the content from the origin server or the main server and then saves a copy of the content for future requests. Cash content remains on the CDN cash as long as users continue to request it. Well, what about graphql queries like where we going with this? Well CDs know how to cash resources when they actually have those requests headers. We talked about attached to that. But can we use those request headers with graphical queries? Yes, we can we can set cash control header on a graphical query right? Well, except we usually use resources that are query documents but 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 cash control last modified and some e-tax headers to it. But even though that is possible in theory since graphical use post. But in action we basically can attach. Those headers to post and we need to use get. So that's why they come to persist this queries as solution number one to go around attaching those headers. We talked about to graphql course. A central principle in rest right that we talked about is that you use a URL to identify a piece of data a piece of resource and then we use gets. Verb in our HTTP request to indicate that you're doing some data read. Otherwise that tells our cdns. It's okay to catch that result since it's not expecting to modify something on the backend. In contrast to that historically most graphical tools and HTTP requests using posts instead of a URL. The users a complete complicated request body that contains a query and variables. As an added complication in some browsers. There is a relatively small URL sized limit. That means you can fit the entire query that you're making and also the variables in the get requests. So what can we do well persist that queries come to our rescue. By combining a polo link our modular network interface for the client and oppose engine automatic persisted queries feature. We can address both concerns at once. After setting up the engine you can easily add a polylink 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 quotes over HTTP gets instead of posts, right? Because the cdns need that get requests to understand that resources are not changing wirelessly using posts for mutations. And second use a shortened persistent query ID in the get URL so that the cash key for cdns is shorter and we don't hit the URL size over minutes. This brings graphical much closer to the regular HTTP get requests. That cdns are designed to handle. Well, what else can we do then persistent queries? let's talk about Polo cash control What's that? With our rest API we can simply return a cash control header from a specific endpoint. just until the writing you endpoint. It will remain. as bright But with graphical we're constantly be improving queries on the front end you're adding field moving Fields. You have different versions of the UI needed. So, how do you make sure your cash control hands stays on today with the shape of the query even as the data included in the result changes over time. That actually what the policash control is designed to solve. This is a step for how graphql server should return cash hints on a pair field level. So here we can see. That comes with the reference implementation for JavaScript that kind of shows us how we could specify cash hands with different levels of assistance specificity. So here we do have the cash hints Mass age of five seconds for the whole schema set. with the cash 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. Right. It doesn't need to be on the whole schema. This is super important because it allows our API to a specify the expiration of different pieces of data. We don't want everything to expires at the same level while maintaining the freedom of the front and code to specify whatever queries it needs. Well cash controls at the end of the day the engine combines all of this hints into one chameleon cash 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 cash 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 you 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 persisted queries with Apollo link. Let's quarries use yet while mutations still use folks second Apollo cash control lets you specify cash control information in a fine granny schema oriented way and third apology generates the smaller query IDs so we can use your Corey's ideas in our get requests without hitting the cash key size and set the cash 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 Nasa death, and I'm looking forward to chat with you all on the Discord channel of the conference. Thank you.