Reading time: 5 min read
Using Vercel’s Data Cache With Sitecore XM Cloud and Experience Edge
Gain an in-depth understanding of what Vercel’s Data Cache is and how it functions with Sitecore XM Cloud and Experience Edge.
Gain an in-depth understanding of what Vercel’s Data Cache is and how it functions with Sitecore XM Cloud and Experience Edge.
Start typing to search...
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.
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.
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.
Just like the Edge Cache, you have a few ways to revalidate your Data Cache. You have three listed below:
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();
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.
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.
There are two methods that have been provided to us.
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
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.