Feat: Store features in memory after loading them from cache

[Grendel7]

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 UnleashRepository implementation, UnleashBuilder doesn'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.

[sighphyre]

Hey @Grendel7, while the situation isn't ideal at the moment I think you're doing the right thing with what you've done. This is something I think we may want to improve at a future date but I don't think we'll do anything soon