Closed aKzenT closed 1 year ago
Hi @aKzenT and thanks for using FusionCache!
Long story short: I am already working on supporting this scenario, see here 😉
I will update you all as soon as there's a design proposal so we can discuss it further.
Thanks!
Hello @aKzenT , I've created an issue to track the design and development of Conditional Refresh, please let me know what you think.
Hi all, v0.21.0-preview1 is out which includes this, too.
Hi, v0.21.0-preview2
is out: one more week of baking and the official v0.21.0
will be released 🎉
Hi all, I just release v0.21.0 which includes this 🎉
Hi @aKzenT , I was wondering if you had a chance of using Conditional Refresh, release in v0.21.0 a week ago. If so, how is it working? Any opinions? Thanks!
Hey,
we did not have the chance to implement the feature yet. It is high on our priority list and I hope we can start with that soon.
From what I've seen, I don't expect any issues though.
Thanks again!
Ok thanks!
A lot of HTTP based backends provide support for HTTP based caching like Last-Modified or ETag.
It would be nice if FusionCache could take advantage of this by tracking and using this data. So in case FusionCache believes that the data in memory cache and/or distributed cache is stale, it could actually allow to check if the information is actually stale or still up to date.
While that sounds complicated, I actually believe this could be added fairly easily by providing an alternative factory function.
If provided, this factory function would not only return the requested object but also an optional ETag and LastModified timestamp. FusionCache can store both inside the cache entry. Whenever FusionCache has an entry available that is considered stale and is asking the backing store for an updated value, it would pass both ETag and LastModified to the factory function. The factory function can use these values to set apropriate HTTP headers and can either return an updated value or a "NotModified" indicator. When FusionCache receives a NotModified return value, it will mark its existing value as non-stale (i.e. treat it as if that value was returned from the factory).
To simplify/abstract it might be enough to support a single string value only. Since the factory is in complete control on how to interpret the value, it could treat it either as an ETag or a LastModified date depending on what the backend supports.
This feature would have multiple benefits. Not only does it reduce load on the backing store, but it also avoids spending time serializing/deserializing data that has not been changed. For example, we have a large CMS where a single page can consist of hundreds of objects that need to be deserialized. A lot of time the data is refreshed even though it has not been changed. There is no way to detect this though and we spent uneeded time throwing away the existing objects in memory and deserializing the same data again, causing memory fragmentation and CPU cycles.