Feat: allow separate cache driver to be used for stale cache
eblanshey opened this issue · 3 comments
Is there an existing issue for this?
- I have searched the existing issues
Describe the new feature
There are two levels of caching currently: the 30s short cache, and the stale cache which is longer. Additionally, there is a way to provide a bootstrap file that can be used in case a request to the server fails. So in essence there are 3 ways of falling back to something if a request fails.
A bootstrap is persistent, whereas the caches are temporary. What I would like is to have a more persistent "stale" cache, that stores the result of the latest known request. This is better than a bootstrap file that needs be manually updated with the latest feature flags.
The stale cache that's currently implemented works well, but uses the same cache provider as the short term 30s cache. The two usages are quite different: one is for frequent requests in a cache store that is ephemeral (like Memcached and Redis with automatic eviction.) The stale cache is more long term and shouldn't be wiped out automatically with evictions, new deployments, etc -- it is used to prevent errors from bubbling up on production.
It would be nice to provide the ability to set a separate cache driver for the stale cache, via the builder, such as with a withStaleCacheHandler() method. The stale cache handler can then use a more persistent storage such as a file or persistent Redis instance. Consider it like a way to auto-populate a bootstrap file.
To make it backwards compatible with previous releases, the stale cache can use the regular cache provider if one is not provided.
Is your feature request related to a problem? (optional)
No response
Describe alternatives you've considered (optional)
No response
Additional context (optional)
No response
Sounds reasonable to me, what do you think, @sighphyre, @ivarconr?
Sounds very reasonable to me, this is pretty close to how most of the other SDKs handle caching so I'm on board with this.
@eblanshey The PR for this has been finalized and is now awaiting code review.