Hey guys, does sanity have some kind of caching mechanism on request? im using the `@sanity/client` in a rn app; the issue is, when I edit a document in sanity and then attempt...

10 replies
Last updated: Jan 3, 2021
Hey guys, does sanity have some kind of caching mechanism on request?im using the
@sanity/client
in a rn app;the issue is, when I edit a document in sanity and then attempt to fetch that document again, I have to run the fetch exactly two times for it to update; any idea why it doesn't update the first time? (I tried waiting over 5 minutes and will not work on the first fetch)
AI Update

This is actually a common issue related to how Sanity's CDN caching works! The behavior you're seeing is by design, and here's what's happening:

When you use @sanity/client with useCdn: true (which is often the default), your requests go through apicdn.sanity.io. The Live CDN uses a stale-while-revalidate caching strategy with a 600-second (10-minute) cache window.

Here's why you need to fetch twice:

  1. First fetch after editing: Returns the stale (cached) content from the CDN, but triggers a background revalidation
  2. Second fetch: Returns the fresh content that was fetched during the revalidation

This is the expected behavior of stale-while-revalidate caching - it prioritizes performance and availability by serving cached content immediately while updating in the background.

Solutions

Option 1: Disable CDN for fresh data (Recommended for your use case)

Set useCdn: false in your client configuration:

import {createClient} from '@sanity/client'

const client = createClient({
  projectId: 'your-project-id',
  dataset: 'your-dataset',
  useCdn: false, // Bypass CDN for always-fresh data
  apiVersion: '2024-01-01'
})

This sends requests directly to api.sanity.io instead of the CDN, giving you fresh data on every request.

Option 2: Use perspective parameter

You can also use the perspective parameter set to 'previewDrafts' or 'published' depending on your needs, but this works best when combined with useCdn: false for immediate updates.

When to use each approach

  • useCdn: true: Best for production apps where slightly stale data (up to 10 minutes) is acceptable and you want better performance/lower latency
  • useCdn: false: Best for admin interfaces, preview modes, or when you need guaranteed fresh data on every request

Since you're building a React Native app where users expect to see their edits immediately, setting useCdn: false is probably your best bet!

If you use Nextjs getStaticProps with revalidate, the cache is in Nextjs. The first hit will always serve from cache and the next hit serves the updated response
as far as I understand nextjs is used on react web; I don't have a nextjs dependency in my project, neither does the sanity client; but I think you're definitely on the right track
Are you using the APICDN by any chance? Urls would be like projectid.apicdn.sanity.io/ ...
yes
user A
that was it, thank you
although I had this page opened https://www.sanity.io/docs/api-cdn I didn't see the configuration
usesCdn: true
it doesn't seem to be worth it though; will speak to my client and explain what's happening there
just out of curiosity, im assuming most of the users use the apicdn, the tradeoffs doesn't seem that big
It varies a lot actually. If you can live with slightly stale data we highly recommend it for robustness and latency. But it is a tradeoff against freshness.
Using the api will hit our document stores every time.
stale-while-revalidate
is set to 600 seconds, so that is how old content we serve while fetching fresh in the background. If it is older than 600s you will have to wait for fresh content.

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?