🎛️ Declarative Cache Control

[martinbonnin]

Follow up from https://github.com/apollographql/apollo-kotlin/issues/3566

Allow to extend the schema on the client with directives:

extend type Query {
  currentMinute @maxAge(60)
}
extend type Day @maxAge(86400)

[ynkm169]

Hi, it sounds like this ticket is to support expiry on a query level. Would we be able to have expiry on fragment level as well? https://github.com/apollographql/apollo-ios/issues/142

[BoD]

@ynkm169 the idea here was to control the expiry per type rather than per query or fragment. Since several queries and fragments can contribute the same fields to the cache I'm not entirely sure how this would work - but don't hesitate to tell us more about your use case and the possible API you envision.

[ynkm169]

@BoD Hi, per type work as well. I am wondering what edge cases may we run into if we do it per type? In other words, does it have drawbacks that we need to make trade offs on?

• Apollo Kotlin does not support partial cache hit. However, I imagine if done per type, you will never have partial cache hit issues since you are always querying part or all of a type.

[BoD]

Apollo Kotlin does not support partial cache hit. However, I imagine if done per type, you will never have partial cache hit issues since you are always querying part or all of a type.

@ynkm169 situations where you will get a cache miss even though some fields are present in the cache can still happen. If a field is expired, it should behave like it is missing, and so this will result in a cache miss as well. For instance:

query getProduct {
  product(42) { 
    description { title }
    inventory { quantity }
  }
}

If description is not expired but inventory is, this should be a cache miss for product.

[ynkm169]

Hi, to clarify. Will we get ability to specify expiry both

1. on the schema type
2. and also override the type on a particular query or fragment?

#1 will serve as a mechanism to provide default expiry on a type #2 will serve as a mechanism to override expiry on a type per query/fragment

[BoD]

I think 2. should be possible but it could be hazardous in the sense that if your field correspond to a record that is also returned by another query (cache key based on its id for instance), then this could lead to unpredictable results.

[ynkm169]

#2. There are many cases regarding expiry specified in different locations that may affect the same cache entry.

• type level expiry < query/fragment A expiry override < query/fragment B expiry override
• query/fragment A expiry override < type level expiry < query/fragment B expiry override
• query/fragment A expiry override < query/fragment B expiry override < type level expiry

I think this may introduce unwanted behaviors. A surface/API expect a particular cache entry to expire in 1 minute, another surface/API may modify this entry's expiry to 30seconds or 2 minutes.

Based on above, I think we wouldn't need #2 at all.

[ynkm169]

Hi, is there an approximate timeline in terms of having this declarative cache expiry feature available for memory cache? Is it on the near term roadmap say within a 6 months timeline? Thanks!

[BoD]

Our current focus is on version 4 which currently doesn't include this, and is expected to land around ~ Autumn 2023 (see the roadmap), and then we'll probably work again on this area after that.