Updating Content on the Edge

I've recently started using Sitecore JSS with Next.JS and Vercel, which uses static site generation to deliver content at lightning speed. In my experience so far, I've found that this experience is far better for the end user, but more difficult for the content authors. Why? Because it can be surprisingly difficult to get the site to update when you make content changes in Sitecore. The reason why Next.JS (and static site generation in general) is so incredibly fast is because it pre-generates every site on the page and caches it. When a user requests a page, Next.JS is able to deliver it from cache almost instantaneously with no server-side load time. Individual pages are regenerated when they are published in Sitecore, and Next.JS sees in the Layout service that the content has changed. However, as a content author, sometimes you have to take some extra steps to get a page to update in the browser.

Publishing an item does not necessarily update the pages that show it

Next.JS is smart about regenerating pages when related items are updated. For example, if you update a datasource item, every page that refers to that datasource item will be regenerated. However, sometimes pages have content that isn't linked in Sitecore. For example, you might have code that directly gets an item by hardcoded ID (like global configuration items). If a page is dependent on a global item, but that relationship is not visible in Sitecore's Link Database, Next.JS will not know to regenerate the page when the global item is updated, because the page data in the Layout service has not actually changed. In this case, you'll need to force Next.JS to update the page. You can do this by republishing the page, which updates the pre-compiled page data in the Layout service, thereby making Next.JS detect the changes. But if there are a ton of pages that use this item, you might need to republish the whole site or redeploy your production branch to Vercel. You may want to consider architecting your Sitecore pages so that any such items are linked to a field on your page, so that Edge can pick it up automatically when the data item is changed.

Asynchronous content is cached in Next.JS, and you must tell it to revalidate

Next.JS doesn't only cache pages. If you update content that is pulled from indexes or accessed with GraphQL in your code, you might find that no matter how many times you republish the page, it won't update. This is because anything that is fetched asynchronously gets generated by Next.JS and cached by Vercel too. To make sure that your components update when the content changes, you must tell Next.JS to revalidate all asynchronous calls. From the Next.JS documentation: "Next.js will automatically create a Serverless Next.JS Function that can revalidate when you add next: { revalidate: 10 } to the options object passed to a fetch request."

const res = await fetch('https://api.Next.JS.app/blog', { 
    next: { revalidate: 10 }, 
  });  

Here is another example in getStaticProps, the Next.JS function used to get content asynchronously:

export const getStaticProps: GetStaticComponentProps = async (_rendering) => { 
  try { 
    const fields = _rendering?.fields as LatestNewsListingComponentFields; 
    const result = await getStaticPropsForLatestNewsListing(fields); 
    return { 
      result, 
      revalidate: 1800 
    }; 
  } catch {} 
  return {}; 
}; 

If you don't have revalidate in your code, it will never update until you deploy again in Vercel or purge all of your data.