Cache expiration question

[padupuy]

Hi folks, I use apollo-cache-persist on a mobile app and I'm looking for a solution to get data if it exists, from the cache, else get it from remote.
I am aware of apollo cache policy but the cache-first value is not really a good solution for me.

I have a simple product list, when I click on a row, the detail screen is displayed and a product request is fired, so the request result is stored is the cache.
Then, I go back to the detail list.
Imagine 5mn later, I update my back office to change the product price.
If i go back to my detail screen, the product data will never be updated if I use the cache-first policy and will be always updated if I use the cache-and-network policy

Is there a way to add a cache expiration, maybe in minutes or hours ?

[jamesreggio]

Hi @padupuy —

Unfortunately, that's not possible today. Supporting per-key metadata (including a TTL/expiration time) is on the roadmap for the next major release, but it's unlikely to become available prior to then, due to the significant API changes it would require.

#2 has a broader conversation around cache filtering/expiration, and I expect we'll continue the conversation over there once it's time to implement this feature.

Until then, I'd suggest you stick with fetchPolicy: 'cache-and-network'. apollo-link-dedup can help to mitigate the number of HTTP requests made to fulfill the 'network' half of that perhaps-too-aggressive fetch policy.

[padupuy]

@jamesreggio thank you for your kind answer and your suggestion I already use apollo-link-batch-http.
Any idea when next major version will be release ?

[jamesreggio]

You're welcome! Not sure about the next major version, but not anytime soon.

[visheshd]

Hi @jamesreggio, I wanted to check if this is still on the roadmap? Thanks.

[wtrocki]

@visheshd Roadmap is available here #94 . Feel free to suggest new items.
This package is maintained by the community and we looking for contributors interested in improving this package.

[visheshd]

@wtrocki Happy to contribute. Are there any specific guidelines for this repo?

[wtrocki]

Cache expiration is actually one of the main features of the Apollo Client 3.0.
The community also providing the number of workarounds to achieve that for the moment. Doing that in cache persist is not an option as the removed item will be written again from InMemory store. We are happy to accept any suggestions but in some cases like this, we will be constrained by the modular architecture of the Apollo ecosystem.

See: apollographql/apollo-feature-requests#4 (comment)

[hwhh]

Hi @jamesreggio,

I was hoping to find out if there were any updates regarding TTL/expiration times?

[wtrocki]

@hwhh is this question in relation to Apollo 3.0. Generally TTL are handled on cache level.
Persist is just saving what cache has.

[hwhh]

Hi @wtrocki,

Thanks for getting back to me, yes this question in relation to Apollo 3.0; I opened an issue here apollographql/apollo-client#6484 (comment) but saw this issue too. I am not sure if it is possible, but (at least when using react-native) when items are persisted in the background, would it also be possible to remove expired items in the background as well?

[disarticulate]

quick hotfix for me to invalidate cache regularly:

const persist = await persistCache({
    cache,
    debounce: 100,
    storage: new LocalForageWrapper(graphqlStore),
  })
  const TTL = localStorage.getItem('graphql-persist-TTL')
  const TTLfuture = new Date().valueOf() + (60 * 1000 * 60) // 1 hour
  if (!TTL) {
    localStorage.setItem('graphql-persist-TTL', TTLfuture)
  } else if (parseInt(TTL) < new Date().valueOf()) {
    localStorage.setItem('graphql-persist-TTL', TTLfuture)
    persist.purge()
  }

ok, this doesn't work because apparently nothing is returned? Seems odd to not return the object the cache is based on. gonna need to monkey patch it.