Feat: Store features in memory after loading them from cache
Opened this issue · 1 comments
Is there an existing issue for this?
- I have searched the existing issues
Describe the new feature
When the Unleash client is called multiple times within a request, it should load the features once (whether from the Unleash server or from cache) and reuse it for the duration of the request, to prevent unnecessary network calls.
Is your feature request related to a problem? (optional)
Right now, any time Unleash::isEnabled is called, it calls DefaultUnleashRepository::getFeatures. This function then loads the full feature set from cache to be able to tell whether this particular feature is enabled.
In my application, some requests have Unleash calls peppered across them to add certain changes to certain parts of the page, and each of these calls loads the data from cache.
I'm using Laravel with a Redis cache. While Redis is fast, it's still a network call, so it's not free. And dozens of extra calls to Redis to obtain the same information repeatedly for every request generates noticeable performance overhead.
Describe alternatives you've considered (optional)
I have considered extending the functionality of certain classes to add the memoization myself, but:
- Since virtually every class is
final, I'd have to copy-paste substantial parts of some classes myself. - I had a hard time figuring out how to just replace the
UnleashRepositoryimplementation,UnleashBuilderdoesn't appear to have this option as far as I can tell. - I think that this would make sense to have this in the client by default, it's not an issue specific to my use case.
My current workaround is to implement and use a special tiered cache store that stores the values in memory as well as in Redis. But that's just hacking around the limitation using the controls available.
Additional context (optional)
The naive approach would be to just load the features into memory and reuse them as long as they are available. However, this would cause problems for long running requests, like background workers or using servers like FrankenPHP, so some checks for freshness of the in-memory data would be helpful.