Cache expiration question about apollo-cache-persist

[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)

[visheshd]

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

[hwhh]

Hi @jamesreggio,

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

[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?

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

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

[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]

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

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

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