Whenever the age of the resource we fetched will be greater than this max-age, the client will emit a request instead of using the value in its cache. This is especially great for data that doesn’t change often, such as browser assets. For example, a server returning this Cache-Control header is telling clients not to bother fetching this resource again until it has been at least one hour (3600 seconds): Freshness lets the server transmit, through Cache-Control and Expires HTTP headers, the time for which a resource should be considered fresh. There are two concepts that are particularly important to understand when it comes HTTP caching: freshness and validation. Gateway caches are usually deployed along with a server, to avoid requests from always hitting servers if the information is still up to date at the cache level. Client side caches, such as browser caches, use HTTP caching to avoid refetching data that is still fresh. There are multiple parts to HTTP caching that are important to understand before we go further.įirst, there are many different cache entities that can be involved in HTTP caching. This causes issues around certain things, like HTTP caching.
Drupal graphql caching full#
Since GraphQL is transport agnostic, most server implementations out there use HTTP as a “dumb pipe”, rather than using it to its full potential. While certain API styles like REST make great use the powerful HTTP semantics, GraphQL does not really, at least, by default. So if we can actually cache things both at the server and client layers, why are we hearing so much about GraphQL “breaking”, or making caching really hard? This is where it becomes more nuanced.
Drupal graphql caching update#
Next, if you’re familiar with popular GraphQL clients, you know one of their major feature is a denormalized cache that allows client side application to avoid refetching data they already possess, using it to optimistically update an UI, and to keep a consistent version of the world across components. We will dive deeper into some concepts that can be applied at the application level later on in this chapter. At this point, we know that GraphQL can actually be a thin layer over our existing servers, and that in no way GraphQL prevents us to cache on the server-side, sometimes referred as Application Caching. The first thing to understand is that “server-side caching” is already vague. This is a common thing to see thrown around when talking about GraphQL. What kind of caching? Client side? Server side? HTTP caching? Application side caching? To have a proper discussion and end with a better understanding of GraphQL’s limitations in terms of caching, we must be more nuanced. Before we dive into the world of caching and GraphQL, it might be a good idea to address these common concerns, and understand where they come from.Ĭomments like “GraphQL breaks caching” lack the nuance required to actually have a proper discussion about caching and GraphQL. This is something I see some companies starting to use GraphQL being scared of and for which they don’t have a clear answer on. If not, I guarantee you’ll be hearing similar things when you start displaying interest for building a GraphQL API. If you’ve followed the discussions around whether GraphQL is a good idea or not, you might have heard things like “GraphQL breaks caching”, or “GraphQL is not cacheable”. If you’re interested in learning more about the book, I would really appreciate if you signed up for the newsletter. It is an introduction to a caching & performance chapter, taking a look at the whole caching & GraphQL situation to remove confusion and show a more nuanced way of looking at it. This post is a preview of my upcoming book on GraphQL.
0 kommentar(er)
