We at Dyte are super excited about the fact that we're growing at a super-fast pace, and so is our software delivery cycle. Almost every sprint, we introduce new features. However, the ever-increasing number of customers with different requirements warrants the need for an effective way to manage the feature delivery process as well. All of the features are not intended for all of our customers. The features that are not intended for all, are shipped behind the flags (indicators/controllers). These flags basically control the recipient of any such new features. In the software industry, the flags are commonly referred to as feature flags.
Before we dive into why Dyte chose Flagsmith for feature flagging, let's make sure we're all on the same page about feature flags.
The What's and Why's of Feature Flag
First thing first -:) Let's understand what Feature Flags are! A feature flag is a feature management solution that allows users to change the software's functionality without deploying new code. You can hide the code or behavior of software using feature flags without shipping new versions of the software.
In the simplest terms, consider the feature flag as a powerful "if" statement:
Feature flags go by different names (to list a few), in the software industry:
- Feature Toggles
- Feature Switch
- Release Toggle
- Feature Controls
Feature flags allow developers to conditionally turn on or off specific sections of their code (or code paths).
Now, come to why's:
There are a few ways to look at when you should use feature flags. Some of the most common use cases are:
- Show or hide a button to access a new feature
- Test a UI change
- Try a new call to action to see how it performs
- Let users try an experimental use case
To understand it better, imagine you're working on a feature that doesn’t provide support for all browsers yet or cannot be deployed in all geographic locations. For example, the new functionality is bound to work only on Chrome, and the standard support is not there yet for other browsers. Maybe the functionality doesn’t pass compliance of a few specific countries. In such a situation, you can use feature flags to manage the features easily.
A feature flag is a method of controlling the delivery of a specific feature (for example, user engagement metrics or facial gesture detection) to a subset of clients, countries, and browsers rather than rolling out all features to all clients.
You can easily create and manage feature flags with an advanced and user-friendly flag management platform, such as Flagsmith. Your changes can be applied in real-time, eliminating the need to deploy and ship your solutions repeatedly.
This is especially useful for SDK solutions like Dyte, where the release cycle is too agile. We can now instantly enable/disable a feature without requiring our clients to spare their developers countless hours in deployment.
At Dyte, we evaluated multiple possible options and solutions before reaching the final decision!
- We could have used a third party such as Flagsmith or LaunchDarkly.
- Build an in-house solution.
After extensive discussion and evaluation, we decided to go with a third-party solution that is expert in this area. There were several reasons for this decision, but the most important one for us was not spending our developers' time and energy on something that was not our company's primary goal.
The next step was to figure out who:) This required a lot more research!
We wanted a solution that was cost-effective while still meeting our requirements.
There are many common and expected features of a feature flag solution, such as segmentation, flag types (boolean, string, JSON), A/B testing, and percentage rollouts, but we dug even deeper to find a solution that provided the most customization in terms of performance and functionality while remaining simple to use and integrate, just like Dyte!
So we researched, compared, and came up with a comparison table.
~ denotes approximately
— denotes “Information not readily available”
|Function / Parameter
|SDK size (Vanilla JS)
|~ 23 KB
|~ 40 KB
|~ 101 KB
|~ 108 KB
|~ 47 KB
|SDK size (React)
|~ 39 KB
|~ 64 KB
|~ 123 KB
|~ 119 KB
|~ 59 KB
|SDK Support (Go, Java, Swift)
|Load testing availability
|Website navigation index on the scale of 1-5. 5 being the most painful
|Docs navigation, index on the scale of 1-5. 5 being extremely painful
|Tracking the flags which were enabled for a session/call
|YES (it was possible by having Integration of Webhook/ New Relic)
|YES (Needed events or integration)
|NO (We needed to add our own solution)
|Dashboard to view audit logs
|Ways to find/define flag dependencies
|API Call response within xx ms
|We could control it by having our custom-hosted solution. 100ms was the SLA expectation of flagsmith. https://docs.flagsmith.com/advanced-use/edge-api
|45ms to 400ms
|130ms to 400ms https://status.split.io/
|SLAs for issues
|99% uptime or 10% credit https://flagsmith.com/service-level-agreement/
|https://launchdarkly.com/policies/enterprise/premium-sla/ (Response in 1 day to 1 week or Pay more, 98% uptime or 10% credit)
|No clear SLA.
|99% uptime or moneyback if an issue arises for 2 months consequently https://www.split.io/legal/terms-of-service/
|Response in 4 hours to 2 days based on the plan. 99.9% uptime. https://devcycle.com/pricing
|What I liked?
|API was easy to use and verbose. Functions such as hasFeature were aptly named. We could create our own infra as well as contribute. It is Open Source.
|Documentation was better and rich. Promised the closest solution to what we needed.
|Drag and drop for the layman. Advance event tracking to get insights in Optmizely’s in-built metrics section.
|Better metrics and alert policies. A lot of features were really advanced but feel like overkill.
|Extremely easy docs to follow.
|What I didn’t like?
|Docs were not updated or were updated in advance at various places.
|Information was not readily available on the website. The free account had various limitations so couldn’t play around. SDK functions were named poorly.
|Website navigation was not as intended. Features were called decisions, looks weird to read the code.
|Weird naming conventions. The entire system was named believing that it will only serve A/B testing.
|Still in the nascent stage. No
*Evaluation as per March 2022
The Deciding Factors
For us, the most crucial points apart from the functionality were SLAs (can’t let the ship sink with others), SDK size (we are an SDK ourselves, bundle size matters, cannot afford more KBs), ease of use (API structure, Doc navigation), and the price.
We found Flagsmith to be the best solution available for our requirements. It had all the features, the ability to self-host, and more reasonable SLAs. Best of all, a very easy-to-follow API docs (https://docs.flagsmith.com/clients/rest). And just a single API call can do it all; no need to open a Postman collection and hit your head against the wall for days 😊
The cherry on top is that it is open source. If someday we get stuck on a requirement, with the help of a league of extraordinary folks, we can always contribute to their open-source codebase.
Given these considerations, we concluded Flagsmith to be the richest platform with a significantly lower fee.
Thanks to Flagsmith, we could avoid burning a hole in our pockets. Other service providers would have charged ten times the price for comparable features.
If you haven't heard of Dyte yet, go to https://dyte.io to learn how our SDKs and libraries revolutionize the live video and voice-calling experience. Don't just take our word for it; try it for yourself! Dyte offers free 10,000 minutes every month to get you started quickly.