Skip to content

[docs] Update advanced-topics on SSR cache #11956

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
smyrick wants to merge 1 commit into from
Closed

[docs] Update advanced-topics on SSR cache #11956

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions docs/source/caching/advanced-topics.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,14 @@ title: Advanced topics on caching in Apollo Client

This article describes special cases and considerations when using the [Apollo Client cache](./overview).

## SSR and Caching

We reccomend against a long-running Apollo Client instances in the server. For SSR it has the risk of memory leaks, outdated data and sensitive user information leaking between users, and query deduplication does not look at headers. Every Client instance on the server should always be short-lived - one per request. The only long-living Apollo Client instance should be in the user's browser.

If a short-lived client makes requests that don't contain any authentication information, the request cache (like from Next.js) can take over and answer those requests from the cache - but that kind of caching is outside of the scope of Apollo Client, as this is very complex and already provided framework functionaliy that we do not need to duplicate on top.

It is also not reccomended to add any persistence unless you want to build an offline-ready app, but using Next.js would probably not be your first for that solution.

## Bypassing the cache

Sometimes you _shouldn't_ use the cache for a particular GraphQL operation. For example, a query's response might be a token that's only used once. In cases like this, use [the `no-cache` fetch policy](../data/queries/#setting-a-fetch-policy):
Expand Down