How to pass next fetch options to getClient.query()?

[paales]

For a general fetch call next.js supports fetch options:

fetch('http://localhost:3000/api/graphql', {
  cache: 'force-cache'
  next: {
    revalidate: 1000,
    tags: ['bla', 'bla2'],
  },
})

In the README fetchOptions: { cache: "no-store" }, is suggested as a possible solution to disable nextjs' cache, which works, but this is on a global level and I think this will disable the cache for the complete route (not sure yet).

We'd like to do something like:

const { data } = await getClient().query({ query: userQuery, revalidate: 1000, tags: ['bla', 'bla2'] });
// or
const { data } = await getClient().query({ query: userQuery, cache: 'no-store' });

Maybe this is already possible, but wasn't clear to me how this should work.

[patrick91]

hi @paales, yes this should be already possible by doing the following:

  const { data } = await getClient().query({ 
    query,
    context: {
      fetchOptions: {
        next: { revalidate: 5 },
      },
    },
  });

[paales]

Ohh, thanks! That makes sense. I was confused because of the lack of typings in in the context.

[phryneas]

About the typings: unfortunately, those would need to be different for every link you are using - these are for HttpLink, but if you were using something else it could have very different config options. So we unfortunately can't type that here :/

[paales]

I'm trying to make sense how to combine the fetchPolicy and the fetch cache option. I've written it out, what do you think about this conclusion?

Cache configuration on queries:

• Apollo client's fetchPolicy
• Next.js' fetch cache option

Request dedupe:

• Apollo Cache: Recreated for each Request, so used for deduping queries that can be resolved by Apollo's cache.
  • This is smarter than React.cache as this can also dedupe queries that request a smaller set that are in the set of a previous cached result.
• React.cache: Deduping fetch calls.
  • This functionality can not be disabled in Next.js, but in this case, the functionality is completely redudant because of the Apollo Cache.
• fetch cache: Next.js new fetch cache, dedupes fetch calls between different requests.
  • This is the functionality we want to leverage as this allows us to cache fetch calls between requests and allows for seamless revalidation.

fetchPolicy	cache	Request chain
cache-first, standby	force-cache	Apollo Cache -> ~React.cache~ -> fetch cache -> fetch
cache-first, standby	no-store	Apollo Cache -> ~React.cache~ -> fetch
network-only, no-cache	force-cache	React.cache -> fetch cache -> fetch
network-only, no-cache	no-store	React.cache -> fetch
cache-only	?	Apollo Cache

The difference between cache-first and network-only is that we're leveraging the React.cache instead of the Apollo Cache. Since the Apollo Cache is superior to the React.cache, we should probably only use the Apollo Cache and thus only use cache-first.

I can't think of a possible cache-only use case in a RSC environment, ideas? This looks like the only-if-cached RequestCache property, but that isn't documented in the next.js docs, they probably didn't think it made sense.

My conclusion: Always have the fetchPolicy set to cache-first and use Next.js cache property to handle any any caching between requests.

[paales]

About the typings: unfortunately, those would need to be different for every link you are using - these are for HttpLink, but if you were using something else it could have very different config options. So we unfortunately can't type that here :/

We're creating a wrapper for the getClient().query() so we'll handle it there.

[phryneas]

I'm doing some housekeeping so I'm closing some older issues that haven't seen activity in a while. If this is still relevant, please feel free to reopen the issue.

[github-actions[bot]]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.