[@NaukriEngineering] Feature Toggles
3 likes623 views
Feature toggles allow teams to modify system behavior without changing code by using a binary condition to control whether a feature appears in an app. They can be configured in different ways like hardcoded, through parameters, or in a database. There are different types of feature toggles like release toggles for new features, operational toggles for operations, and experiment toggles for A/B testing. When implementing feature toggles, the best approach is to remove conditionals, strategically create objects with dependencies injected, and encapsulate toggle logic in a routing layer to avoid coupling code to the toggle system and proliferation of conditionals. It is important to keep the number of toggles low and remove unused toggles.
[@NaukriEngineering] Feature Toggles
- 2. Introduction Feature toggles are a powerful technique, allowing teams to modify system behavior without changing code. It is a binary condition that controls whether a feature appears in the app or not.
- 3. Example Feature Toggling context Toggle configuration Toggle router function apply() { if (featureIsEnabled("newApply")) { return applyWithNewAlgorithm(); } else { return oldFashionedApply(); } } Toggle point
- 4. Categories ● Release toggles ● Operational toggles ● Experiment toggles ● Permission toggles
- 5. Configuration Management ● Hardcoded ○ // return applyWithNewAlgorithm(); ○ return oldFashionedApply(); ● Parameterized: command line, environment vars ● In files ● In database. Accompanied with admin UI ● Distributed: zookeeper, etcd, consul etc...
- 7. Harcoded ❏ Rigid ❏ Requires manual intervention ❏ Can’t be automated ❏ Error prone ❏ Requires redeployment class Apply { ……….. // return newApply(); return oldApply(); }
- 8. Point Toggles class Apply { ………. // fetch config from somewhere ……….. if(config.newApply) { // go to new apply } else { // go to old apply } }
- 9. Point Toggles ❏ One feature, many toggle points ❏ Decision point coupled with decision logic ❏ Messy code that is difficult to maintain ❏ Lacks separation of concerns ❏ Difficult to incorporate toggle scope changes class Apply { // fetch config from somewhere …… if(config.newApply) { // go to new apply } else { // go to old apply } …… …... if(config.newApply) { // do something } else { // do something else } …….. }
- 10. Indirection ❏ One extra concept that Apply is aware of ❏ Coupling with an extra module ❏ Can’t think of Apply in isolation ❏ More and more modules get coupled with feature toggle system ❏ Feature toggle system becomes a global dependency ❏ Unwanted proliferation of conditionals class FeatureDecisions { // fetch config public void isNewApply() { return config.newApply; } } class Apply { // read isNewApply() from FeatureDecisions if(isNewApply()) { // go to new apply } else { // go to old apply } }
- 11. Remove conditionals ❏ Strategic creation of objects ❏ Dependencies injected ❏ Easy to add and remove toggles ❏ Apply is unaware of feature toggle system ❏ Encapsulates if/else statements into the routing layer class FeatureFactory { …... if(featureDecisions.isNewApply()) { new Apply (new ApplyWithNewAlgo()); } else { new Apply (new OldFashionedApply()); } }
- 12. Keep inventory low ● Remove toggles that are no longer needed ● Remove dead code ● Limit the number of toggles ● Don’t create technical debt