[daigoba66]

As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime.

Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience).

Do many apps really need A/B testing or segmented rollout? Maybe, but probably not.

[hsn915]

Is "feature flag as a service" the new trend in backend development?

Why would anyone replace a literal byte in memory with a full program?

Why?

[bratbag]

Because feature flags often intersect with segmentation and AB testing.

So it's not just a byte in memory, but often also correlating the status of said byte with a users identity and then tracking and summarising user behaviour based on that relationship.

It's become fairly standardised and requires engineer time to setup and maintain the services behind all that, so it's valid to go third party for less than the cost of said engineer time, if all you want is standard.

Edit:it's also hard to always predict when a standard flags going to become part of a test, so just integrating for every flag and making that a standard process for your teams becomes the simplest approach.

[sverhagen]

I am not a fan nor a user of backend feature flags, so don't ding me for relaying this: they tout features such as central management of these settings, bringing them in the hands of the product team rather than being tugged away in code, allowing for canary deployments where you fade in a feature based on performance metrics, a/b testing, and so on. In their own interest, these folks take an as broad as possible view on what is a feature flag, often including things that you'd otherwise call system configuration or entitlements or permission toggles. It's not a new trend, LaunchDarkly is probably the best known commercial party here, and they've been around for about ten years, and I don't think they were first.

[politelemon]

I wouldn't say a new trend, it did go through a hype cycle a few years ago, and some teams have adopted it. I definitely wouldn't call it a standard practice though, as it brings with its own overhead. In effect you've got "byte in memory as a service" with its own deployment, maintenance, and statefulness. It's only useful if you have a business model that really relies on having this capability. That could be in a sufficiently large, already complex, sprawling application estate, having a single flag in a central location could be useful if several pieces of your sprawling estate need it.

[mvdtnz]

"Just use a database table" solves for the simplest cases - a single monolithic app. It works incredibly well in this case. It falls apart when I need to turn features on across multiple apps together.

[ehnto]

I think OPs point was a simple app doesn't need this whole suite of tools, but you pay for them anyway, which makes it a bad cost/value proposition for simple apps.

So yes a more complex situation could benefit from all this extra tooling and complexity but otherwise it is dead weight/cost.

[mrweasel]

Then you use etcd or consul.

I would claim that release a new feature by enabling additional code path across multiple apps at once is a bit of an anti-pattern. It seems rather dangerous and error prone. In that case I'd actually release it in reverse order, so to speak. Release the apps that use the services of others first and have it check is this service is available/functional and if not, skip calling it. The release the feature to the next service down the stack. Then you can always rollback the last service and be confident that the callers still work.

It's way more work and I can see why for certain types of application isn't not really worth the trouble.

[mvdtnz]

The point of feature flags is to decouple releases from deployments.

[mrweasel]

Then you just have a feature flag per app.

[oftenwrong]

Multiple apps can access a single database, so where's the problem?

[mvdtnz]

Sure, they could. Doesn't mean they should, or do.

[JimDabell]

> Just use a database table" solves for the simplest cases - a single monolithic app.

Most cases are the simplest cases.

No approach works for every single use case, but OP was specifically talking about the common case. You don’t have to shoot for the most complex use case every time.

[ehnto]

I think most frameworks I have worked with have the concept of configurations, more advanced ones have config that can be overriden by environment files. Definitely a solved problem if you want to roll your own.

.env files are the quick and dirty version for simple sites that don't have an admin panel or database.

[samtho]

This technique has been used since Wordpress days and earlier. At it’s core, it’s a “meta” table with a string identifier and some value. It’s a pattern I still use today in my own web apps.

[smileysteve]

Most apps lack users for A/B testing to be significant; and the product teams to develop in an isolated enough way to avoid biases.