Re:Feature Flags: Theory vs. Reality
by benpapillon on Monday July 10, 2023 @02:07PM
(#36670467)
I think a lot of the solutions come close but don't quite get there. It seems like there's kind of a divide between the open source solutions that are probably more sensitive to the day-to-day pain points of developers and the bigger managed service players that seem to be optimizing for contract size.
Hadn't thought of the frontend build hashing idea - like that a lot
I feel your pain.
This is what drove me to build an open source solution: https://featurevisor.com/
- local/static access: it should not have to call out to a 3rd party server to get basic runtime config
- unused-flag detection: flags should have three reported states: never used, recently used, not recently used. These will be different from the user-controlled states of active, inactive, etc.
- sticky a/b testing: should follow the logged in user until the flag is removed
- integration with logger: I should be able to use it with my logger out of the box to report only relevant feature flags. Alternatively can provide a packed value of all relevant flags, would probably have to do flag state versioning.
- integration with linter: should warn me if flag has not recently been used or I used a flag in the code that is not in our database (alternatively, will upsert the flag automatically if it doesn’t exist)
- hashed flag names on frontend build: prevent the leakage of information, not a perfect solution, but I would want to avoid writing “top-secret-feature” where we can.
I fully acknowledge that a lot of solutions come close, but I haven’t looked at the current state of things in the last few years so it may have improved.