How resilient is your current feature management system? What happens if failing network requests keeps 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 independent 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 a permanent storage where the SDK does not have access to a 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

Get started

First; update your Unleash client dependency to 4.2.1.

GAV coordinates for unleash-java-sdk
Update the references

Load order

The Unleash client SDK already performs regular backups of 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 latest known state from your Unleash instance at build time could look something like this:

Dockerfile

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 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)
Java example S3 provider

and use this when configuring Unleash

Configure S3 in 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.

Examples

All code used in this post is available in the Unleash Java SDK examples repo.