Bootstrap Unleash Java SDK – to improve the resilience
How resilient is your current feature management system? What happens if failing network requests keep you from reaching your feature management service? You don’t want a situation where your app is unable to function properly because the feature toggle configuration can’t be loaded. As part of our commitment to resilience and robustness, we are introducing additional strategies for bootstrapping predefined values. This is part of your feature toggle best practices.
The first SDK to receive this feature is the Java SDK, and is available in the 4.2.1 release, with Golang support soon to follow. Let’s explore this new feature.
What is bootstrap?
Bootstrap refers to providing the SDK with predefined values for the feature toggle configuration. This will allow Unleash SDK to execute independently of the network connection. This makes sense in situations when the client application network connection towards the Unleash server is not available during boot up. Such consideration is part of the feature toggle best practices. This new feature will also allow you to define permanent storage where the SDK does not have access to permanent storage, e.g. in a container scenario.
This blog post will take you through how to get started using bootstrap for the Unleash Java SDK
First; update your Unleash client dependency to 4.2.1.
The Unleash client SDK already performs regular backups of the latest known state from the API. On startup, if a backup file is available, that will take priority over the Bootstrap provider. It is not currently possible to override this priority, if you’re sure you want to load your bootstrap, delete the backup file (usually found in the /tmp folder).
If there’s no backup file, or the backup file contains no feature toggles, the Unleash client SDK will try loading state using the Bootstrap handler.
Using a file on disk
By default, the Unleash client SDK configures a ToggleBootstrapFileProvider which loads the file specified by the UNLEASH_BOOTSTRAP_FILE environment variable.
This variable should be set to the location of a downloaded backup of your feature toggles.
A minimal Dockerfile to prebake the latest known state from your Unleash instance at build time could look something like this:
Using a file on classpath
The provided ToggleBootstrapFileProvider also supports loading from the running applications classpath, so if you’re baking your feature toggle state into a fatjar that’s what you should use.
For instance, if you’ve stored your json at /toggles/bootstrap.json inside the jar, set UNLEASH_BOOTSTRAP_FILE to classpath:/toggles/bootstrap.json and the SDK will load the packaged json file.
Using S3 to store toggles
To avoid bloating the core library with extra dependencies, we’ve only included support for loading toggles from the disk. However, the ToggleBootstrapProvider interface is public and only has a single method to implement, so adding support for AWS S3 should be rather easy.
First, you’ll need to add S3 library to your classpath. The maven coordinates are
- GroupId: software.amazon.awssdk
- artifactId: s3
- version: 2.16.29 (or newer)
and use this when configuring Unleash
This should allow you to have code that syncs state from the Unleash API server to an S3 bucket and use this to get your Java application to a known toggle state at startup.
All code used in this post is available in the Unleash Java SDK examples repo.
Want to get started using Unleash and Bootstrap?
|GET STARTED||TRY OUR DEMO|