[FEATURE] Support of Caching PSR-16

[legoheld]

Requirements

It would be nice if the SDK would support caching of the flag requests. For example add a psr/simple-cache compatible cache storage and then store the results for better performance. This way not every provider has to implement its own caching.

I looked into hooks but as far as I understand its not possible to implement a caching hook. The return type is always just an EvaluationContext so its not possible to prevent requesting within a hook.

[tcarrio]

This is likely a larger discussion for the OpenFeature specification. The SDK adheres to the spec and there is no formal caching definition.

Likely the best way to handle this though, in my opinion, is this can be done by decorating an existing provider with a cache proxy provider. All of the uncached interactions would pass through but otherwise the cache would return early.

Many flagging systems have some form of telemetry or analytics that provide business value around flag evaluations. Caching is something that directly hijacks the providers logic, thus having unintended impact to those analytics. For this reason I don't believe any language with an OpenFeature SDK provides this officially as part of the client

[beeme1mr]

We've talked about this in the past and decided that caching should be a provider concern. It may be possible to create a caching provider that essentially wraps a provider to enable a consistent caching experience.

[legoheld]

Funny I just made a refactoring in the FliptProvider where I made a wrapper CacheProvider that could be used with any other providers.

[tcarrio]

That provider could definitely be reused, but provider developers and SDK consumers need to know the trade-offs. If you are caching the response such that the underlying provider is not called at all, you are missing impressions data, which in many cases is used by businesses to understand the performance of the features behind the flags.

If you want to introduce it to the contrib or publish it as a general package that would work. Please do include the caveats though. Many underlying providers can support caching out of the box while still providing meaningful analytics around the usage, but a pattern like the CacheProvider will act as if no flag evaluation occurred.

That's primarily the reason that this is not technically supported in the specification- most vendors did not want a generalized caching mechanism like this. But consumers can decide on that trade-off themselves :slightly_smiling_face: