Apollo-client: [Design] Cache expiration / invalidation strategy

Created on 23 Oct 2016  路  7Comments  路  Source: apollographql/apollo-client

The current thought process behind cache usage is in reading or rereading data from the store. A => B (cache status) => A. When reading data from the store (before making a query, or via currentResult), AC would check against a cacheInfo store within the apollo reducer. If the lastRequestTime - now is past the time specified in the ttl, it treats it as empty data. If not, it reads it from the store.

_store_

{
  queries: { },
  data : { id: { field: value } } },
  cacheInfo: { id: { field: { lastRequestTime: Date } } } 
}

Initial usage idea:

cont observable = client.watchQuery({
  query: gql`{ menu { link, title } }`,
  ttl: 86400 // one day (in seconds)
});

_Note_
Currently there is not callback on expiration. In this sense, cacheInfo is passive until data is read. However, the cacheInfo store would allow for things like a redux middleware to check all expired data times when, for instance, an offline app comes back online. In that case it, it may be helpful to link back to a query to be able to call refetch() but that isn't part of the first build out.

Thanks @stubailo for the discussion.

Thoughts?

Most helpful comment

Its actually a really good point that we can't figure out this data, especially the node IDs, without the result. So it's not something we could do at request time.

All 7 comments

Is that lastRequestTime mean lastReponseTime?
I think we should count ttl after client received response?

Hmm, I think request time might be a good idea because you probably don't want to refetch if a request is already in flight?

In that case it's look like requestInfo more than cacheInfo to me.

I think cacheInfo will happen only after response from server only before that it should be empty (or maybe we can use rehydrate time stamp as lastRequestTime?), maybe I'm over thinking, please ignore me in that case ;)

Its actually a really good point that we can't figure out this data, especially the node IDs, without the result. So it's not something we could do at request time.

So, can que actually use that "ttl" parameter right now in our watchQuery calls or this is still in dev?

@Dunos it was just a proposal, nobody has started implementation yet.

I'm closing this, please refer to #621 for updates on this topic

Was this page helpful?
0 / 5 - 0 ratings