Taking advantage of Vercel’s Data Cache ability can mean a simple method of improving your site’s performance. Before we get into the how let’s explore what Vercel’s Data Cache is and what it isn’t.
What is Vercel’s Data Cache?
Think of Vercel’s Data Cache as an extremely efficient way of storing data that your application would normally retrieve from a Graph QL query against the Edge network in Sitecore. This might be something as simple as an item list in a data folder or something more complex as the entire structure of your site’s top navigation.
The huge benefit of taking advantage of the Data Cache is that it doesn’t matter what the underlying site is. Static, dynamic, it doesn’t matter. The data you’re fetching can then be revalidated with the route it’s on.
What Vercel’s Data Cache is Not
It’s entirely understandable to be confused by all the “cache” options you have within Vercel’s network. After all, there are several, and each one has a specific purpose.
Right off the bat, most people will be confused between Data Cache and Edge Cache. Edge Cache, however, is the caching of entire page layouts, images, or other static assets that are delivered as part of a route rendering.
Given the Data Cache is a shared cache, it’s not one that can be personalized, as all users of the application will be sharing the same cache. So, you have to keep this in mind if you’re ever trying to pull data that might be location-based. Something like that is not a place where you’ll want to utilize Data Cache.
How is Vercel’s Data Cache Revalidated?
Just like the Edge Cache, you have a few ways to revalidate your Data Cache. You have three listed below:
- Time-based
- On-demand
- Tag-based
What is Time-based revalidation for Data Cache?
Just like Edge Cache, Data Cache is no different in this regard. It can be set up to revalidate at a particular interval. At such time, identified content will be labelled as stale and will then be re-fetched.
If we wanted to cache a fetch against Experience Edge using Graph QL query, this is one way we could do that. Obviously, there are GraphQL utilities you can use, but I wanted to explore how to use the revalidation.
const customHeader = {
'sc_apikey': config.sitecoreApiKey,
};
const requestBody = JSON.stringify({ graphQLQuery, variables });
const queryRequest = await fetch('https://edge.sitecorecloud.io/api/graphql/v1', {
headers: customHeader,
method: 'POST',
body: requestBody,
next: {
revalidate: 3600, // 1 hour
},
});
const queryResponse = await queryRequest.json();
What is On-demand Revalidation for Data Cache?
You have the ability, again, like Edge Cache, to trigger a revalidation of the data manually or through a process such as a Sitecore publishing pipeline.
What is Tag-based Revalidation for Data Cache?
This is one feature I love. You can effectively “tag” a fetch with a particular value. Let’s say you’re doing a fetch of news releases. Then in another fetch elsewhere, you’re performing a fetch for all the years that news releases exist for. Well, you can “tag” both fetches with the same value, and thus you can use the function revalidateTag to force the revalidation for all fetches with the same value.
Again, if used during a Sitecore publishing pipeline, this can be extremely handy. You don’t have one data cache clearing and another staying cached. You can make one call and clear them all.
From a code perspective, it looks like this:
const customHeader = {
'sc_apikey': config.sitecoreApiKey,
};
const requestBody = JSON.stringify({ graphQLQuery, variables });
const queryRequest = await fetch('https://edge.sitecorecloud.io/api/graphql/v1', {
headers: customHeader,
method: 'POST',
body: requestBody,
next: {
tags: ['news'], // Invalidate with revalidateTag('news') on-demand
},
});
const queryResponse = await queryRequest.json();
The important part is the next section where it sets the tag to news.
The following code would be used to revalidate all data cache with the news tag.
import { Request, NextResponse } from 'next/server';
import { revalidateTag } from 'next/cache';
export async function POST(req: Request) {
revalidateTag('news');
return NextResponse.json({ revalidated: true, now: Date.now() });
}
Of course, all that said and done, you may not want to use it at all.
How to Disable and Not Use Data Cache in Vercel
There are two methods that have been provided to us.
- Disabling Data Cache as a whole
- Preventing a single fetch from caching the data received
Disabling Data Cache Outright
You can very simply use the following command:
export const fetchCache = 'force-no-store';
You would place this at the top of your layout.tsx or page.tsx or route.ts file.
There are other commands that go along with it, if you were curious. They are:
auto | default-cache | only-cache | force-cache | force-no-store | default-no-store | only-no-store
Preventing A Single Fetch From Using Data Cache
You would then use the following inside your fetch command.
{ cache: 'no-store' }
It would, as a result, look something like this:
const queryRequest = await fetch('https://edge.sitecorecloud.io/api/graphql/v1', {
headers: customHeader,
method: 'POST',
body: requestBody,
cache: 'no-store',
});
I hope this helps you improve the performance and reliability of your headless XM Cloud implementations.
