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

Garbage collection in apollo store #3965

Closed
mike-marcacci opened this issue Oct 1, 2018 · 2 comments
Closed

Garbage collection in apollo store #3965

mike-marcacci opened this issue Oct 1, 2018 · 2 comments

Comments

@mike-marcacci
Copy link

mike-marcacci commented Oct 1, 2018

I'm hoping to resurrect the conversation started long ago in #41. I'm working on a map-based app which queries the server with new coordinates whenever the map is moved. This results in a huge number of cached objects and queries which are nearly useless, and slow down the app drastically.

Furthermore, our requirement for eventual offline support means that we've separated timeless "entities" from their state, and create a unique object (with its own unique UUID) for each version. This compounds the problem, as each version of each entity is cached indefinitely when a user is making edits, even if their usefulness is short-lived.

We had garbage collection in Relay, but encountered so many other problems and a total lack of communication, so this caveat was easy to swallow many months ago when we switched to Apollo. However, this is quickly becoming a priority, and I'm willing to lead the charge on getting this implemented.

However, I want to make sure I don't miss any work that's already been done on this, or make design choices that conflict with something else in the Apollo roadmap.

Adding reference counting and purging of no-longer-referenced Nodes (to borrow Relay's terminology) seems like an internal implementation detail, and doesn't concern me too much. However, we also need to add a mechanism for user-land code (or a framework-specific SDK) to inform Apollo when a query is no longer referenced. This should probably share some degree of symmetry between the different supported languages (js, swift, scala, etc).

I'd love to hear if the core team already has some thoughts about this.

@pl12133
Copy link

pl12133 commented Oct 3, 2018

Cache eviction just made it on the v3 roadmap, here is the main issue: apollographql/apollo-feature-requests#4

If you want to try this yourself, I would start by trying to implement InMemoryCache::evict:

public evict(query: Cache.EvictOptions): Cache.EvictionResult {
throw new Error(`eviction is not implemented on InMemory Cache`);
}

@hwillson
Copy link
Member

hwillson commented Jul 9, 2019

This is being tracked in apollographql/apollo-feature-requests#4, so closing here. Thanks!

@hwillson hwillson closed this as completed Jul 9, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants