Getting StartedCache Revalidation

Revalidation of cache is an important aspect of server-side rendering and is a key part of the Next.js caching strategy.

We are utilizing DatoCMS Cache Tags to revalidate GQL queries on demand, when relevant records are updated in the CMS.

When an update is made, a webhook is triggered and sends a request to the website’s API to revalidate the cache. The API routes are defined in each project, under /api/revalidate (see Forge for example). Each new project needs to configured with the correct endpoints after the fork of Forge has been done.

Updating the webhook

  1. First make sure the project package.json name field has been updated to the new project name.
  2. Go to the project’s DatoCMS dashboard.
  3. Go to the project’s settings.
  4. Go to the webhooks section.
  5. Open or create the “Invalidate cache tags” webhook.
  6. Set the URL to the new project’s API route (example.com/api/revalidate/cache-tags, probably a vercel.app url before prod deployment)
  7. Add a new “Custom header”
  8. Set key to Webhook-Token and set the value to the same value as the WEBHOOK_TOKEN in the .env.local file and Vercel environment. ℹ️ The WEBHOOK_TOKEN should be generated via 1password if the project does not yet have one.
  9. Save the changes.

🔂 Repeat this procedure for any staging environments.

Circumventing Vercel deployment protection

Most projects will have deployment protection enabled, usually in the form of a password. This can be circumvented via a custom header:

  1. Go to Vercel Project Settings -> Deployment Protection
  2. Under “Protection Bypass for Automation” add a secret key, generate one via 1password and make sure it is shared.
  3. Go back to Dato and add the x-vercel-protection-bypass header in the webhook request with the generated secret key.
  4. Save the changes.
Deployment - Quick Guide1. Pre-production