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

Add cache eviction / expiration #142

Open
emilien-io opened this issue Sep 13, 2017 · 5 comments
Open

Add cache eviction / expiration #142

emilien-io opened this issue Sep 13, 2017 · 5 comments
Labels
caching enhancement Issues outlining new things we want to do or things that will make our lives as devs easier

Comments

@emilien-io
Copy link

Hi there!

Following our discussion w/ @martijnwalraven on Slack, I think that would be very helpful to implement cache eviction and expiration functionality.

Let's use this ticket to discuss possibilities and compare what other Apollo SDK are doing.

@designatednerd designatednerd added the enhancement Issues outlining new things we want to do or things that will make our lives as devs easier label Jun 25, 2019
@winstondu
Copy link
Contributor

@designatednerd , has there been any progress made on this?

I'm not fully familiar with the discussion around this, but here in broad strokes is what I am asking:
From a developer standpoint, I want to be able to specify in my query that I want to go to cache for some information that I am requesting, but not others. For example:

query PersonInfo($id: String) {
  person(id: $id) {
    birthcertificate  // Once this is cached, it is cached forever. I should just always get this info from the cache if available.
    age // I want to have this have a TTL of a few days before invalidating the cache and going to network instead
    legalName // I want to always go to network for this information. 
  }
}

Currently, to do this the way I would want to, I end up writing three different queries, one for each TTL. (Of course, because this query is so small, I could just go to network for everything. But you can imagine that not being an option for a larger query).

@designatednerd
Copy link
Contributor

There's several open pull requests from @Mordil on this if you'd like to take a look - they're going to be a bit since @martijnwalraven has taken a big sledgehammer to the cache and there'll need to be some fixups, but it'd be great to have feedback.

@Mordil
Copy link
Contributor

Mordil commented Nov 25, 2020

One of options we've been discussing is possible setting a TTL at a fragment level. Doing something so fine-grained as individual properties might get very hairy and not scale that well.

Thanks for the use case - it's good to know how developers are wanting to be able to use the framework, as I only know how I'm using it for the work I do

@winstondu
Copy link
Contributor

@Mordil , yes a TTL at a fragment level is more than fine. If you have a PR up for that, we would love to use it! It would save us a lot on server usage.

@ynkm169
Copy link

ynkm169 commented Mar 22, 2023

Hi, just to upvote this thread.
In our app, for our Retrofit implementation, we implemented ability to specify client side memory cache expiry on any requests.
For GraphQL migration, fragment level expiry would be absolutely nice to have.

One issue is nested fragment.

  1. Parent fragment has 10s expiry, nested fragment has 100s expiry. Cache fetch should succeed.
  2. Parent fragment has 100s expiry, nested fragment has 10s expiry. Cache fetch should fail. Apollo Kotlin currently does not support partial cache hit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
caching enhancement Issues outlining new things we want to do or things that will make our lives as devs easier
Projects
No open projects
Development

No branches or pull requests

6 participants