When off-the-shelf solutions exist for a problem, you should think twice before implementing one yourself. The same holds for feature management systems. At first, it looks simple enough to roll your own. But dig deeper, and you might realise building it is trickier than it seems, and it sucks away a lot more resources than anticipated. Precious resources that you should dedicate to building and improving your core product.
Feature flag management is a complex domain. On the outset, it appears to be a few simple
ifs in your codebase. But to take advantage of feature flagging, teams need developer-friendly libraries, ergonomic admin interfaces, quick & reliable configuration delivery endpoints and supporting tools with great DX.
The four pillars of a feature flag service
To appreciate all the benefits of a feature-flagging SAAS, let's take a look at what Appknobs.io has to offer.
- Ready to use client-side libraries
- Administration Console
- Fast configuration delivery
- CLI tools for development and CI
Are you interested in the details? Read on!
Client-side libraries that solve recurring problems
To implement feature toggles on the client side you need to take into account the traits of the underlying UI framework or library. It's not enough to grab the list of enabled features from a service. The information has to be available at the right time, in the appropriate format and at the correct decision points of the UI hierarchy.
Our React library solves this problem in a way that respects the characteristics of the particular library and ecosystem. It enables declarative, expressive coding of features, contributing to productivity and maintainability. It takes care of edge cases, performance issues and works as you would expect any React library. It solves server-side rendering problems too, so you don't have to.
In short: it saves you a lot of experimentation, coding and testing, giving you straightforward tools to work with.
Update: @appknobs/angular is now available!
Want to know more? Take a look at our React, SSR, React Native & Electron example implementations!
One key concept of feature flagging is the separation of code from the decision to enable or disable a feature. This division is how you can change the behaviour of your application without modifying or re-deploying code. The decision is based on any aspect of the actual runtime environment or the user or a combination of these. Examples include looking at the username, email address or group membership of the user, the hostname or code branch of the app instance and so on.
To make these decision points manageable, we provide a web-based Console. This UI allows stakeholders to list applications and their managed features and pipe the runtime information into feature switches.
Users can log in, adjust conditions as required and ensure the behaviour of the application changes from that moment.
The Console tutorial: read how to create new users, register your applications, set features and define the conditions when these features will be visible
The third problem domain is getting the actual feature configuration to the application instance at runtime. An app instance means each visitor to your website or each user of your mobile app.
The Appknobs service client library saves you from having to implement the authentication, HTTP requests, data transport from client to the decision service and handling the responses.
Our services take the information from the instance - this is called the "payload" in Appknobs - and match them against the conditions previously set on the Console. These services are fast, available globally and scale to match high demand.
The integration of clients and back-end endpoints is continuously tested, ensuring reliable service.
What's more, Appknobs provides client implementations that work in various environments, so you can keep using the same service across applications written in Node.js, React, Rect Native, Electron or any browser. Plus, our support matrix is expanding to cover other popular frameworks such as Vue and Angular.
The last piece of the puzzle is our CLI tool package. We have created @appknobs/cli because we believe that good DX (Developer Experience) is not just a nice to have, but it is essential.
For some tasks, web UI is the optimal solution, but developers are more productive on the CLI. Also, there are some tasks you will want to run on a CI server, and we wanted to help there too.
With our command line tool, you can
- Automagically discover features in your codebase
- Register applications
- Get information about the current app, such as name and
- Remove apps and clean up quickly, feel free to experiment
- Grab your API key
- Register new users
Automatic feature discovery is powerful. Thanks to our declarative UI library, you can issue a simple command and ensure that all features in a given codebase are discovered and also registered.
Would you like to find all the features in your app and then open the web console to adjust conditions? Easy! Simply run
$ appknobs parse src/
$ appknobs console
Do you want to ensure all features are registered on the CI? Even simpler:
If you think about it, it is much more than a handy tool: having features registered directly from the codebase eliminates human oversight and saves you valuable time that is needed elsewhere.
Intrigued? Check out the README of @appknobs/cli
Build vs Buy
As you can see, this is a lot of ducks to line up and a lot of moving parts to take care of.
If you set out to replicate a similar system, the usual journey of planning and exploration begins. Choices about architecture, technologies, languages and libraries have to be made. You write code - probably lots of it - that need to be reviewed, tested, deployed, QAd and maintained. At the end of the day, you have to support another product, sacrificing time and energy.
Creating your solution is the appropriate answer in some cases though. You might want to try new ideas, new approaches. Working on hard problems and coming up with great answers is how the world moves forward, after all.
The question we like to ask before deciding on “buy vs build” is the following: is this our core product? Companies are wise to create bespoke solutions for their differentiating product - the “who they are” - but save time and money and use available services for everything else, if possible.
Few experienced teams maintain their source repos, write their CI server or bug tracker or implement a PAAS from scratch - and the list goes on. With good reason: these are just tools. If the tools are good enough, why not focus on producing real value for your customers instead of reinventing the wheel?
And why would feature flagging be different?