Skip to content
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.

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

Change Apollo cache strategy #4914

Open
FelixMalfait opened this issue Apr 11, 2024 · 0 comments
Open

Change Apollo cache strategy #4914

FelixMalfait opened this issue Apr 11, 2024 · 0 comments
Assignees
Labels
scope: front Issues that are affecting the frontend side only T

Comments

@FelixMalfait
Copy link
Member

As of today we are using "cache-first" strategy and "in-memory" storage.

Instead we would like to introduce a persistent storage through https://github.com/apollographql/apollo-cache-persist/ (most likely LocalStorage).

Instead of using fetchPolicy we will use:
initialFetchPolicy: cache-and-network
nextFetchPolicy: cache-first

The idea is that the cache coming from localStorage is considered to be less trustworthy (we weren't connected to the app so objects might have changed) - with this setting we ensure that users see cached data immediately for a fast initial load while updating with fresh data from the network.
On subsequent load, the data should be trustworthy because we'll have websocket so we can keep the current setting which is cache-first.

I tried to do a quick proof of concept:

  • integrating "await cachePersist" as it's recommended within Apollo provider would have required some refactoring because it's currently initialized in a useMemo ; I'm not sure we need to await for cache persistance since our initialFetchPolicy is "cache-and-network" which will through a request anyway this seems superfluous to me so I left it this way
  • it worked well for all objects except clientConfig and getCurrentUser which somehow didn't get cached properly. I could see that even if I was setting initialFetchPolicy to cache-first, it was still making a request for those 2 which slowed down the initial rendering of the app. I didn't investigate much further
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: front Issues that are affecting the frontend side only T
Projects
Status: 🆕 New
Development

No branches or pull requests

3 participants