Should OSR template include calls to cacheLife?

[mjarosch]

Description

Should the OSR template include calls to cacheLife in the cache helper methods (getSitecorePage, getSitecoreDictionary, ...)?

According to the NextJS documentation:

We recommend setting a cacheLife in every use cache scope so its behavior is clear at the call site. Omitting it leaves the lifetime implicit (the default profile applies), which makes it harder to reason about, for example in nested cached scopes.

The default profile has a revalidate of 15 minutes. So OSR will really only cache for that amount of time without this?

Additional information

No response

[benitoalba]

Hi there! The helpers use Next.js's default cache profile: getSitecorePage has 'use cache' and cacheTag, but no cacheLife call.

The 15 minutes is the revalidation interval, rather than a hard expiration, a subsequent request can serve the cached result while a background refresh runs. Tag-based invalidation can happen sooner.

Calling cacheLife explicitly would make the policy clearer, as the Next.js docs recommend. For example, to use the hours profile:

import { cacheLife, cacheTag } from 'next/cache';

export async function getSitecorePage(params: GetSitecorePageParams) {
  'use cache';
  cacheLife('hours');

  // existing fetch and cacheTag calls
}

Choose the profile that fits your publishing policy; keep the existing tags for on-demand revalidation.

[mjarosch]

The Sitecore documentation doesn't mention any time-based lifecycle for revalidation API options. To me, that implies that they would never be refreshed, which can have usage implications for hosting providers like Vercel.

Ideally Sitecore would update their docs for the revalidation API to mention the default revalidation interval and update the template to include a cacheLife('default') to make it explicit.

We can, and will, update the default methods, but prefer to keep the OOTB provided items as close to stock as possible to make upgrades easier. Having upgraded from the JSS SDK to Content SDK then from Pages to AppRouter and now from ISR to OSR, keeping things as close to stock as possible has made life a lot easier.

Thanks for the confirmation of the way the caching works, it's much appreciated.