Unleash vs. LaunchDarkly

In the previous article, we introduced the timing and usage scenarios of feature toggles. In this article, we will pick two of the more well-known solutions, Unleash and LaunchDarkly, to provide a basic introduction and my experience.

Before I begin, let me briefly describe what the essential requirements for a feature toggle solution must be.

1. Easy-to-use website.
2. Easy to integrate SDK.
3. Ability to implement 4 types of feature toggles.
   • Release toggle: You can percentage rollout to achieve canary deployment.
   • Ops toggle: Similar to the release toggle, the percentage adjustment function is also required.
   • Experiment toggle: To be able to carry additional information within the toggle, not just true or false.
   • Permission toggle: When making toggle judgments, it is important to be able to use additional dynamic parameters such as user id.

Both Unleash and LaunchDarkly can satisfy these three criteria, and although there are some differences in capability, the basic operation of the feature toggle is not a problem at all.

Unleash

Unleash is a mature solution for feature toggle, providing not only an online paid solution, but also a self-hosted open source solution. Therefore, I believe it is very suitable for internal experiments in organizations, after all, it is free. If you have good results with feature toggles, then you can consider upgrading to Unleash's enterprise solution or switching to another solution.

Unleash's open source solution is very simple in architecture, requiring only an API and a PostgreSQL. There is no cache in the system architecture, so you can understand that every time you get a feature toggle it is run directly on the database, but if you only apply Unleash to the backend environment and only use the server-side SDK, then this amount of usage is indeed not a big deal.

On the other hand, the SDK provided by Unleash uses a polling mechanism, asking for results every 15 seconds and storing the results in each instance's memory. This also effectively reduces the frequency of actually touching the database, but at the price of taking up to 15 seconds for changes to take effect. From my point of view, 15 seconds is not an intolerable period, so it is completely acceptable.

It is also very simple to use, first initialize the Unleash instance, and then it will work properly. All the following examples use Node.js as a demonstration.

const unleash = require('unleash-client');

unleash.initialize({
  url: 'https://YOUR-API-URL',
  appName: 'my-node-name',
  environment: process.env.APP_ENV,
  customHeaders: { Authorization: 'SOME-SECRET' },
});

The initialization process needs to set environment, but in an open source solution this parameter is irrelevant because the open source solution only provides one set of environments. Ideally, it should be possible to generate a corresponding set of settings with various online environments, eg: staging and production.

In an open source solution, the only way to distinguish between environments is by using the name of the toggle as follows.

const stgToggle = unleash.isEnabled('featureA-stg');
const prodToggle = unleash.isEnabled('featureA-prod');

This can be quite useful when the number of toggles is small, but when the number of toggles becomes large, it can be challenging to manage.

How to use Unleash to make an expirement toggle? We can do this by using Unleash's unleash.getVariant, which is additional information that can be attached to the feature toggle and is easily configured on the Unleash web page.

const variant = unleash.getVariant('featureA');

In addition, it is very simple to complete the permission toggle, just bring in the context when isEnabled.

const context = {
  userId: '123',
  sessionId: '123123-123-123',
  remoteAddress: '127.0.0.1',
};

const enabled = isEnabled('featureA', context);

Furthermore, Unleash offers multiple different deployment strategies.

1. Standard: Every time, the result will be the same.
2. Gradual rollout: It can be set to a specific ratio, so that the result of each time the toggle is asked is determined by chance.
3. UserIDs: Use userId in the context to enable targets that satisfy a specific userId.
4. IPs: Use sessionId in the context to enable targets that satisfy a specific sessionId.
5. Hosts: Use remoteAddress in the context to enable targets that satisfy a specific remoteAddress.

Thus far in the introduction, we should be able to satisfy the essential use cases of feature toggles with Unleash. However, the functionality of Unleash is very simple in terms of toggling, and there are several challenges that are not easily overcome in the use of Unleash.

1. There are only three special contexts that can be used for the deployment strategy, and there is only a judgment of equal or not, and there is no operator provided for either greater than or less than. If you need to implement custom strategy, you have to inherit the base class of SDK and implement it by yourself.
2. Unleash supports the use of multiple policies on a single toggle, but the relationship between the policies is OR. For example, it is not possible to enable a toggle to a specific user in a specific location because the userId and sessionId cannot be AND.
3. When choosing a gradual rollout, it can only set one specific rule. For instance, you cannot group by userId and have 40% of the users enabled, because you cannot mix multiple conditions. Otherwise, you can only use totally random distribution.

LaunchDarkly

LaunchDarkly is another common solution. It does not provide a free open source solution, in other words, it is only available as a paid commercial solution.

It is very similar to Unleash in use, and requires initialization at first.

const ld = require('launchdarkly-node-server-sdk');

const client = ld.init('YOUR_SDK_KEY');

Unlike Unleash, it does not need to set the environment parameters in the initialization, because the key has already defined in which environment. The next step is to pick up the corresponding feature toggles.

const user = {
  firstName: 'Bob',
  lastName: 'Loblaw',
  key: 'example-user-key',
};
const value = await client.variation('YOUR_FLAG_KEY', user, false);

Two things are worth noting here: LaunchDarkly's user is equivalent to Unleash's context, but LaunchDarkly's user is more flexible; Unleash's context is only available for those specific attributes that are predefined, but LaunchDarkly can use any attribute and only needs to be configure it on the admin page.

Another point is that Unleash splits the toggle and extra information into two methods, isEnabled and getVariant, but in the LaunchDarkly world, the toggle and extra information are one and the same. That is to say, the value you get through variation already contains the extra information. The value can be a boolean, an integer, a string, or JSON, depending on the setting.

As for the percentage rollout provided by Unleash, LaunchDarkly also provides it, and it is even more powerful. Not only setting a ratio, LaunchDarkly is a composite attribute toggle, so more than two possibilities can exist at the same time, so you can directly adjust the percentage of each possibility in the percentage setting.

In addition, LanuchDarkly provides a very powerful rules engine. Unlike Unleash's monotonous deployment strategy, LauchDarkly can freely set rules for AND, OR, IN, and other matching operations. Moreover, during the percentage rollout, it can also mix percentages and various rules to achieve a very strong conditional matching.

Due to LaunchDarkly's entirely freestyle user and powerful rule engine, basically, LaunchDarkly can implement any application scenario you want.

Conclusion

Currently, the toggle update relies on a polling mechanism, so it takes a while for the settings on the website to really reflect on the system behavior. The solution is also proposed in the new version of LaunchDarkly, which provides a stream mechanism to get instant feedback. However, for the system, it must also consider whether the network environment can tolerate so many persistent connections. This is beyond the scope of this article, so I will not explain it further.

In fact, the feature toggle solution provides much more than just the toggle itself, how to do access control, audit log and SSO and other additional features are equally important. However, different payment solutions provide different payment functions, and those functions have actually been detached from the demands of feature toggles, so this article does not introduce those additional functions of Unleash and LaunchDarkly.

In terms of feature toggling itself, Unleash provides a basic experimental environment in which you can build a feature toggling system in your organization with very little overhead. Unleash also provides all the fundamental features required for feature toggling. For an organization that is just starting up, Unleash provides a great experimental vehicle that can be used as a warm start.

Once the feature toggle is integrated into an organization's development process, LaunchDarkly is a good choice for organizations that need to customize the use of the toggle for more situations. LaunchDarkly provides a simple and intuitive experience for setting and matching customization rules.

From my experience, it is sufficient for small organizations to use Unleash, and the self-hosted solution is simple but enough for most use cases. As long as there are no complex rules to match, there is no need to spend money on other commercial solutions, but if you are having more and more management needs with open source Unleash, then it is necessary to consider commercial solutions and evaluate them carefully. In my opinion, LaunchDarkly is also good.