Comment by ricardobeat

8 days ago

Writing your own logic to handle flags is trivial at first, especially if you're running a monolithic app, but quickly grows in complexity:

- distributing flags to multiple services

- broadcasting updates

- caching rules

- audit logs

- product, not eng, will start managing the flags at some point and needs easy access

- custom logic for gradual rollouts, A/B testing

- custom attributes support (used in evaluation)

- managing multi-variant flags

- supporting multiple platforms (backend, frontend, native apps, services, jobs) and evaluation strategies (eager server-side evaluation vs shipping a client-side engine)

There are quite a few open-source options like Growthbook, Flagsmith, go-feature-flag, and Unleash that you can check out for comparison.

12 comments

ricardobeat

Reply
tantalor  7 days ago

> product, not eng, will start managing the flags at some point and needs easy access

How to tell you have a broken engineering culture.

  • Sayrus  7 days ago

    Some flags are meant to be enabled for specific customers, on-demand, depending on what type of contract is signed, under NDA and so on. Over time, many department that aren't "engineering" need to be able to change some flags. That doesn't imply your culture is broken.

    • ccakes  7 days ago

      I think most would say that’s configuration, not feature flags. The differences can be subtle but I at least don’t think they’re the same thing

boxed  7 days ago

Sounds like most of those problems are just problems with microservices generally. Adding a service makes this worse.

tushr  7 days ago

> product, not eng, will start managing the flags at some point and needs easy access

That's the typical pattern and why most tools focus on non-technical UIs. FFlags targets a different niche. Teams where developers want to maintain control over flag logic.

aitchnyu  7 days ago

Do we need a feature flag-aaS if we have a monolith and easy way to add columns to user table?