[epolanski]

> it just reminds me on how feature flags can be misused as application configuration/customization

They literally are configuration.

[tedk-42]

Oh yeah lets make a web request per service invocation to figure out what to serve for the invocation!

Guys this is exactly the kind of banal crap that makes a simple app into a monsterous beast that won't work unless it's connected to the internet.

[epolanski]

There's no web request per service invocation.

Feature flags are set once at startup (or specific events like hard refresh, or new login) and then simply included in the request headers.

It's not rocket science, but I'm sure people are free to overcomplicate it.

[tedk-42]

That's not a feature flagging service then (config as a service! not a thing really...)

I've done both client and server side implementations of the launch darkly sdk and that's how it's done to know client context.

If you're initialising the entire SDK only to load 1 set of configuration items, I'd argue you can host the config as a json file on a CDN and be done with it - feature flagging is overkill.

[epolanski]

Then I'm lost at what the difference would be and why do you need a dedicated service.

Pardon my ignorance.

[tedk-42]

All good - it is something that has been over-complicated for marketing/product reasons.

If you know what A/B testing is, feature flagging can really allow you to nail down how you should deliver an experience to an end user.

We track end-to-end engagements on our websites based on how the content is displayed on a page with more performant layouts/content winning the test to drive users through the funnel.

I don't love it though because it's a lot of waste that gets left over and not cleaned up leaving billing to grow exponentially as flags are continually called for no reason.