SSR: fetchOptions: { cache: "no-store" } does not work.

[hafaiedhmehdy]

Hi Apollo Team, first of all, I want to thank you for this package; it's quite impressive.
Regarding your example for Server-Side Rendering (SSR):

function makeClient() {
  const httpLink = new HttpLink({
    // this needs to be an absolute url, as relative urls cannot be used in SSR
    uri: "https://example.com/api/graphql",
    // you can disable result caching here if you want to
    // (this does not work if you are rendering your page with `export const dynamic = "force-static"`)
    fetchOptions: { cache: "no-store" },
    // you can override the default `fetchOptions` on a per query basis
    // via the `context` property on the options passed as a second argument
    // to an Apollo Client data fetching hook, e.g.:
    // const { data } = useSuspenseQuery(MY_QUERY, { context: { fetchOptions: { cache: "force-cache" }}});
  });

I've been experimenting with fetchOptions and fetchPolicy in queries and can confirm that only fetchPolicy is effective, for example:

const { data } = useSuspenseQuery<{ retrieve: boolean }>(query, { fetchPolicy: 'no-cache' })

The fetchOptions: { cache: "no-store" } setting in the makeClient() function appears to have no effect. I find myself having to specify the fetchPolicy for each invocation of useSuspenseQuery.

Edit:

This is how the testing was conducted:

let currentState = false

const resolvers = {
    Query: {
        retrieve: () => {
            currentState = !currentState // Toggle the state
            return currentState
        }
    }
}

[phryneas]

Hi @hafaiedhmehdy!
These are two different things:

fetchOptions has nothing to do with Apollo Client - it tells the fetch implementation of Next.js to not use the Next.js cache for this query, but instead really fire a query against a server when Apollo Client tries to make a request.

fetchPolicy on the other hand is an Apollo Client option to tell your hook to not use the cache (although, at least for the SSR run and the hydration run, you probably should, as otherwise data cannot be transported from SSR to the browser!).

[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]

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.

[hafaiedhmehdy]

Hi @hafaiedhmehdy! These are two different things:

fetchOptions has nothing to do with Apollo Client - it tells the fetch implementation of Next.js to not use the Next.js cache for this query, but instead really fire a query against a server when Apollo Client tries to make a request.

fetchPolicy on the other hand is an Apollo Client option to tell your hook to not use the cache (although, at least for the SSR run and the hydration run, you probably should, as otherwise data cannot be transported from SSR to the browser!).

Hi, time is flying!

Just to confirm, by default (without fetchPolicy: 'no-cache'), Apollo Client will always use the cached data from the initial build time, even if the server-side data has changed, right? Unless I either set fetchPolicy in each query or change the default behavior with defaultOptions in new ApolloClient (or use strategies like polling for periodic updates). 👀

Edit: Hi @phryneas, it's been a little while again. I'm very excited to share this little gem I'm working on. Could you please confirm if you have time for a quick review? Thank you!

[angad777]

Hey all 👋

This still seems like an ongoing issue.

Appreciate if you have any updates ?

Cheers!

[hafaiedhmehdy]

Hey all 👋

This still seems like an ongoing issue.

Appreciate if you have any updates ?

Cheers!

What's your question exactly?

[naimulemon]

When enabling the no-store cache, the build process fails with the following error:

[ApolloError]: Dynamic server usage: no-store fetch http://localhost:8080/graphql /

[phryneas]

@naimulemon that's a Next.js error that's just wrappen in an ApolloError - you would get the same error message if you did a normal fetch call. Unfortunately I'm not familiar with what it actually causes, but maybe the Next.js documentation can shed some more light?

[naimulemon]

---

@phryneas Thanks for pointing that out!

The issue seems to be related to the dynamic nature of the Next.js page and how it interacts with Apollo's server-side data fetching.

With the error:

• I was not using export const dynamic = "force-dynamic", which causes Next.js to attempt static rendering. Since Apollo's query needs dynamic data at runtime, it results in an error.

Without the error:

• By adding export const dynamic = "force-dynamic", I ensure the page is always rendered on demand, which resolves the issue with Apollo queries fetching dynamic content.

However, as per the documentation, using force-dynamic in some scenarios might not be recommended, especially if it forces dynamic rendering where static behavior is preferred. I'll need to reconsider the strategy depending on performance trade-offs and content requirements.

If you have any suggestions or a better approach, I'd love to hear your thoughts!

---