You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you have a TTL entity e.g a Person and then have a root query e.g GetPeople, if any of the underlying entities under that query expire then it will cause the entire query to be refetched. When explaining the TTL feature you state:
When an entity is attempted to be read from the cache, it will be lazily evicted if it has been in the cache longer than it's TTL duration (specified in milliseconds) and will trigger any queries watching that data to rerun in order to fetch new data.
So in my scenario this works exactly as you've described, if I have a list of people (with some or many which become expired), upon navigating away and then returning to the list view/page the query is refetched.
My question is, is there a way in which some queries can be ignored when setting the type invalidation policy? e.g.
Currently the application we are building has a CQRS backend, meaning that its all event driven. When we send a mutation we simply get a response that the event has been accepted and the action will be done in the near future. On response we modify our cache locally and I was hoping we could use the TTL to persist our changes on write for 15 seconds, upon this becoming expired it should be safe to re query this entity on other calls e.g GetPerson.
However, when I navigate back to our list view we re query as an underlying entity has been modified which can lead to us display stale data as the backend has yet to apply the change.
The text was updated successfully, but these errors were encountered:
Got it, I think I understand the problem. So is this the only time you need to evict the People type? 15s after the mutation? If so, I'd recommend using an invalidation policy instead of a TTL which would be setup a timer to remove the People query in 15s using the evict API or just re-fetch the query directly. You can read about invalidation policies here: https://github.com/NerdWalletOSS/apollo-cache-policies#specification-1
If we do need a 15s TTL on the People type then if the mutation happens and the data will be stale if it re-fetches before the backend has updated the entities, then I'm not sure what might be best. I think something like ignoreQueries could complicate the API and be error-prone since other queries might get added that also need to be ignored and it could be hard to keep track of.
Hey @danReynolds,
When you have a TTL entity e.g a
Person
and then have a root query e.gGetPeople
, if any of the underlying entities under that query expire then it will cause the entire query to be refetched. When explaining the TTL feature you state:So in my scenario this works exactly as you've described, if I have a list of people (with some or many which become expired), upon navigating away and then returning to the list view/page the query is refetched.
My question is, is there a way in which some queries can be ignored when setting the type invalidation policy? e.g.
Currently the application we are building has a CQRS backend, meaning that its all event driven. When we send a mutation we simply get a response that the event has been accepted and the action will be done in the near future. On response we modify our cache locally and I was hoping we could use the TTL to persist our changes on write for 15 seconds, upon this becoming expired it should be safe to re query this entity on other calls e.g
GetPerson
.However, when I navigate back to our list view we re query as an underlying entity has been modified which can lead to us display stale data as the backend has yet to apply the change.
The text was updated successfully, but these errors were encountered: