is apollo client next compatible with unstable cache?

[yanv1991]

Just wondering if we can use apollo client next + unstable cache in a RSC, if not, what alternatives could we consider to cache data in the server?

[phryneas]

That's a very broad question. What would you want to use it for?

Generally, Apollo Client will do normal fetch calls in the backend, so the fetch cache of Next.js would already apply - I'm not sure what you would use an additional cache layer for.

[niloodev]

You can't use on demand revalidation with this Apollo Client. So my idea was to use unstable_cache with apollo client (no cache) to cache the results (because I want to use query batching too)

But i ran into a problem, that is if a disable the cache of the fetch used in apollo, the entire route is gonna change to dynamic route (and I don't want)

[phryneas]

@niloodev I think you might be mixing up some things here: in RSC, we create a new instance of Apollo Client for every incoming request and these start with an empty cache, so all kind of caching beyond "while a request is happening" is the job of your framework's HTTP caching layer.

If you can use "on demand revalidation" without Apollo Client, I would assume that you can use it with Apollo Client as well.

If you're experiencing the opposite, could you share some code so we can see what you are trying to do here?

[niloodev]

@phryneas Basically I want to use Next on-demand-revalidation with query batching. I have an application that fetches many data from the same source (Wordpress) using GraphQL, the problem is: I can't predict how the query is gonna be, because I'm using query batching (and I have many different queries with different tags), so my idea was to use unstable_cache to make the cache layer above Apollo, that way I won't necessarily cache the requests, but the results.

But this leave me to many issues, and one of them is Next detecting that Apollo Client is using a dynamic fetch, and changing the entire route to dynamic.
I can't put the tags into Apollo fetch directly because that would break the queries, since it is batching and is unpredictable.

I can't paste the code since it is from my job, but it would be awesome if you could help me with this.

(And yes, query batching in my application would be the perfect solution, but this kinda makes me HAVE to use Apollo Client since its the best GraphQL client with that functionality).

[phryneas]

@niloodev For that use case, I'd actually suggest to disable query batching on the server (you can still enable it in the browser). It will give you a lot of benefits in the browser, but in RSC, you will have a much better time with Vercel's fetch cache if you have each query as an individual request. Mashing them together might make effective caching impossible.

[niloodev]

@phryneas Okay I will do that, thank you for the help!
I was looking for some external advice since I never did that before.

[yanv1991]

hey @phryneas what is the correct way to handle fetchOptions per requests basis from a RSC? Maybe pass this as a parameter for every requests? The readme shows a all or nothing approach for this. I would like to achieve an individual approach like the one metioned here https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#individual-fetch-requests

[phryneas]

@yanv1991 you'd do

  const { data } = await query({
    query: QUERY,
    context: { fetchOptions: { cache: "no-store" } },
  });

[yanv1991]

closing this ticket since this was solved, thanks!

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