A Software Architect’s Blueprint: Selecting the Feature Flags Platform

In the sea of feature flags platforms, as a software architect, I’ve sailed through many, each with its unique allure and challenges. Today, let me be your guide, unveiling the key features to consider ensuring your choice not only fits your use cases but also sails smoothly with your platform’s performance.

Beyond the Boolean: The World of Possibilities

Rewind to my days as a tech lead, I recall a pivotal discussion with a product manager about selecting our feature flags platform. The product manager, anchored to his past experiences, leaned towards a familiar platform. However, diving into research, I discovered a crucial limitation: it supported only boolean values.

“Why limit ourselves to true or false?” I pointed out. This query baffled the product manager, who questioned the necessity of other data types. Let’s unravel this together with some compelling examples:

Array Or Enum Values:

Arrays are useful to define user roles and permissions. You can control what features different user groups can access. If you want to release features to specific locations or countries, you can assign flags by geographic region. You can use array or enum to represent different product plans or tiers, users can subscribe to.

String Values:

Using string type for feature flags can be useful to dynamically switch between different language versions of your app. You can also switch between different themes or styles by a string flag.

JSON Values:

JSON objects are useful for toggling various configuration settings. Similar use case is enabling or disabling specific parts of a web page or app UI.

Date Values:

Do you want to release a feature at a specific time in the future? Do you want to add limited-time offers to users? In this case date values are handy, but it’s possible to achieve this with string values as well.

As you can see, there are a lot of use cases when other data types are useful and essential. Even if you don’t need non boolean values now, you will most perhaps need them in the future.

Performance

Using a lot of feature flags can significantly impact your platform performance and user experience. It can affect your performance on both the front-end and back-end.

Front-end

If the UI page is rendered based on several feature flags, loading performance can be pretty slow. This is not surprising, if we consider that UI rendering is blocked not only by fetching data, but also by fetching feature flags. In this case, we need a webhook from feature flag SDK to subscribe to flag changes. Unfortunately, ad block browser extensions can block feature flag SDK. In this case we need to implement a bit more sophisticated method for getting feature flag changes in the front-end. I described the solution in one of my previous blog posts.

Back-end

Number of api calls impact server’s throughput. If we need to use feature flags heavily, we need to be able to cache feature flag values and be able to subscribe to its changes. In this case, we need to consider: Does feature flag back-end SDK support caching? If not, is there a webhook to subscribe for changes and then we can cache values manually?

Conclusion

As we dock at the end of our exploration, remember: selecting a feature flags platform as a software architect isn’t just about navigating the present. It’s about foreseeing the future – anticipating complex use cases and understanding their impact on your project’s performance.

Do you have tales of your own, where unique data types or performance challenges with feature flags steered the course of your projects? Leave your comment. I’m eager to navigate through your experiences and learn from other use cases.