Apollo GraphQL client caching strategies

There’s a lot of information about how the Apollo client cache works technically. What I can’t seem to figure out well is how it could be used in for example an application with concurrent users like a CMS? Can and if so, how would a client use the cache as data becomes stale very fast? What are strategies/techniques to determine whether the data in the cache is stale for a specific UX flow etc.

Or are in general the kind of systems where data changes often not suitable for using (GraphQL) client caches…

Anyone any more info about this?

Hi @Daniel_Mil_van :wave: thanks for posting! This is a really interesting topic and the web client’s cache API has enough flexibility to cover many use cases. Taking a step back for a moment, might I ask whether GraphQL subscriptions adequately address the problem you’re describing? I know there’s no perfect one-size-fits-all approach to application development but usually when I hear “cache invalidation” I think “is this a use case for real-time data?” That’s the problem that subscriptions solve. Tinkering with cache controls on the client is a valid approach but it inevitably invites the question of whether you should move from “pulling” data your client thinks it might need to “pushing” data from your GraphQL server to the client.

Here are the client docs for subscriptions in case that’s interesting to you:

And here are some other resources that might be helpful: