apollo-ios

apollo-ios copied to clipboard

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 , 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).

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.

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

@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.

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.