Fetching / Revalidation

[jastaffen]

Hi there! Thank you for building this boilerplate. It's very comprehensive and fully helped me organize / structure my project in a way that I feel looks very clean and elegant.

I have 2 concerns / questions really:

I was wondering how the revalidate tags are meant to work here. I have a groq-powered webhook firing any time something a sanity document is published (or deleted) that then leverages the revalidateTag method in a route handler. The logs in Vercel apear to be showing correct data, but my frontend still has stale data. I'm not sure if I'm missing something in the docs, but figured I'd ask here if you had any advice seeing how masterful you are with the next-sanity package.

Secondly, I see that you're making an API call to Sanity once for data and again in generateMetadata methods. Is this calling the Sanity API twice or is the call itself somehow being cached so it doesn't call it twice?

[nuotsu]

@jastaffen Thanks for the kind words!

It sounds like you have everything set up correctly with revalidateTag, assuming with this setup. I personally have not tested GROQ-powered webhooks for SanityPress particularly yet—though I definitely will after reading this—so I don't have much insight here.

Otherwise, it might also be the revalidate value (documented here) conflicting with this, where SanityPress attempts to revalidate published content every X minutes (1 hr by default).

---

As for the API calls, fetches using tags (essentially all of them) are cached. You can check the logs of which ones are hit/cached if you enable these settings:

// next.config.js
const nextConfig = {
  logging: {
    fetches: {
      fullUrl: false, // OR true
    },
  },
}

And the logged output:

The URLs are truncated here but essentially are API calls to retrieve page data, announcements, etc.

Page data (with metadata) is hit once and stored in cache, then called a second time in generateMetadata, but this time retrieving from the cache.

Let me know if that was helpful!