One of GraphQL’s core tenants is using a single request to obtain only the data you need for a given context. In REST, you would typically perform multiple API requests to get the same data - one request for each entity. Though GraphQL limits the number of network requests, it (typically) mixes multiples entities in a single response.
This co-mingling can make caching especially hard or even impossible. As an example, let’s consider a sports news website that shows a scoreboard of in-progress matches at the top of every page. The details about each team, such as their logo, name, and record aren’t changing often, if at all. The score, however, could change between each page load while the game is active.
Whenever someone navigates between pages, we’d prefer to only fetch data from the origin that’s possibly changed (the score), while pulling static data (everything else) from the cache. Historically, this single field - the score - would render the entire query non-cacheable. Except with Partial Query Caching.
By marking score as non-cacheable but the rest of the query as cacheable, Stellate will retrieve only score from your origin while pulling the rest from the cache.
Partial Query Caching (PQC) intelligently splits the original query into a query for the cache and a query to pass on to the origin - only ever sending one query to your origin.
Automatic Splitting
Simply telling us about your data - whether it’s cacheable and for how long - allows us to handle all of the splitting for you. Stellate doesn’t only split on cacheable and non-cacheable data; we also handle scoped data and data with different maxAges.
Learn More
Our docs site has extensive guides on PQC, including how to enable it. We encourage you to try it out, and look forward to hearing about your experience.