Java SDK Cache

[pontamilselvan]

Hi ,

Unleash SDK has the following caching options in their java SDK. are they available in featurehub?

●Performance – the client SDK caches all feature toggles and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a toggle is on or off ,without the need to poll data from the database.
●Resilience – If the unleash API becomes unavailable for a short amount of time, the cache in SDK will minimize the effect. The client will not be able to get updates when the API is unavailable, but the SDK will keep running with the last known state.
●Built-in backup – The SDK also persists the latest known state to a local file at the instance where the client is running. It will persist a local copy every time the client detects changes from the API.

[IrinaSouth]

Hi there,

Performance – the client SDK caches all feature toggles and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a toggle is on or off ,without the need to poll data from the database.

Yes, FeatureHub stores cache locally for performance too. The features state arrive from the server and stored in the "FH repository" which is locally cached.

Resilience – If the unleash API becomes unavailable for a short amount of time, the cache in SDK will minimize the effect. The client will not be able to get updates when the API is unavailable, but the SDK will keep running with the last known state.

If FeatureHub becomes unavailable, e.g. during an upgrade - you will be able to get feature states from the SDK cache (FH repository)

Built-in backup – The SDK also persists the latest known state to a local file at the instance where the client is running. It will persist a local copy every time the client detects changes from the API.

We do not have the built-in backup, we can add this to our roadmap for the future releases

Some additional info on security, resilience and performance that would differentiate us from other toggle platforms:

Because we have a repository in the SDK, when the state arrives from the server it is stored in this repository and thus locally cached. The connection can appear and disappear, and in fact does by default every 30 seconds (because the server is configured to force a refresh in that time period, this is configurable), but this doesn’t affect the cache. This makes it always resilient. Because it always gets feature state from this local repository (and not from the server), it is also performant. If you are using a Server Evaluated API key, then activation strategies are implemented on the server, and you would use this for security reasons - you do not want your activation strategies which can often contain private information to leak to web browsers and mobile devices for example. You use these for single person clients, so the features are always right for that one person. If you are using Client Evaluated API keys, then everything is local (all decision making state), this is a fundamental requirement otherwise you won’t have acceptable performance for your server code. You always want to have both options, only having one isn’t either secure or performant.

Cheers!

[pontamilselvan]

Thank You for ur detailed reply