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
Cached responses have a fixed expiry date, expressed in the form of a time-to-live which is added to the date/time the response is saved to the cache. If I make a request with a ttl of one hour, then request the same url five minutes later with a ttl of one minute, the cached response is returned and continues to be returned for a further 55min. The current behaviour honours the concept of time-to-live and is similar to the browser cache but it doesn't suit all use cases.
Expected behavior
I expected the ttl to be updated when the same url is requested with a different ttl. I also expected the cached response to be deleted when the requested ttl is less than the elapsed time since the last response was cached.
The above is one way to implement my desired behaviour, another would be to specify cache "maxAge" in milliseconds or "since" date/time in addition to ttl. If max age is specified and ttl is very large, responses would effectively be cached indefinitely, only being deleted when a more recent response is requested.
What is the motivation / use case for changing the behavior?
I'm working on a dashboard app with back-end data that is updated in bursts. I request aggregate data with a ttl of 1 hour because it is expensive to compute, but I also monitor the back-end for new data every 5 mins. When new data is received on the back-end I would like to lower the ttl/maxAge until the burst is complete, then gradually increase it again. There are multiple pages of views and corresponding queries that can be performed, so expiring the entire cache in one hit would not be a good strategy.
The text was updated successfully, but these errors were encountered:
Current behavior
Cached responses have a fixed expiry date, expressed in the form of a time-to-live which is added to the date/time the response is saved to the cache. If I make a request with a ttl of one hour, then request the same url five minutes later with a ttl of one minute, the cached response is returned and continues to be returned for a further 55min. The current behaviour honours the concept of time-to-live and is similar to the browser cache but it doesn't suit all use cases.
Expected behavior
I expected the ttl to be updated when the same url is requested with a different ttl. I also expected the cached response to be deleted when the requested ttl is less than the elapsed time since the last response was cached.
The above is one way to implement my desired behaviour, another would be to specify cache "maxAge" in milliseconds or "since" date/time in addition to ttl. If max age is specified and ttl is very large, responses would effectively be cached indefinitely, only being deleted when a more recent response is requested.
What is the motivation / use case for changing the behavior?
I'm working on a dashboard app with back-end data that is updated in bursts. I request aggregate data with a ttl of 1 hour because it is expensive to compute, but I also monitor the back-end for new data every 5 mins. When new data is received on the back-end I would like to lower the ttl/maxAge until the burst is complete, then gradually increase it again. There are multiple pages of views and corresponding queries that can be performed, so expiring the entire cache in one hit would not be a good strategy.
The text was updated successfully, but these errors were encountered: