141–150 of 189 posts
Earlier quoted context omitted.
It's literally a field in your database. I could never fathom why this needs to be an outsourced service never mind an entire company.
Thank you! I've never understood why this needs to be an external dependency with network requests.
I would happily pay for safely-remove-old-feature-flags-from-the-code-as-a-service.
I've never understood feature flags. How are they fundamentally different to a Boolean in a database?
Cloudflare are winning these days, they’re just lacking good fine grained permissions. You still have to make an entirely separate account for prod, which messes up SSO since one domain can only be bound to one account.
Gold-plated booleans-as-a-service
I’ve seen whole teams at companies set up fail to provide these booleans-as-a-service well. There are whole companies like LaunchDarkly for them. If you boil it down to this, you may as well boil down every service that exists to bits-as-a-service. Turns out theres legitimate business value in these things, and complexity in delivering them.
Earlier quoted context omitted.
Yes, this! I am dying for need of zerotrust enterprise features and am about to have to actually talk to one of the enterprise sales folks, which will chew up a bunch of time and add stress I’d rather avoid.
I don’t think zero trust will be anytime soon, based on this post: https://community.cloudflare.com/t/making-enterprise-product...
Earlier quoted context omitted.
Yes, this! I am dying for need of zerotrust enterprise features and am about to have to actually talk to one of the enterprise sales folks, which will chew up a bunch of time and add stress I’d rather avoid.
Fwiw I didn't think Cloudflare sales was too bad when we dealt with them a year ago--at least compared to some companies.
Earlier quoted context omitted.
> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the fla…
Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application. If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code. When I was at Shopify a couple of years ago they mandated that feature flags had to be shor…
This is the kind of design wisdom that’s both true and difficult to win an argument over.
It reminds me of arguments related to over-engineering and complexity. The principles are super important to having a codebase that scales and continues to be efficient to work in as the team grows, but they are hard to objectively measure.
Locally or in isolation something may sound like a great idea. Being able to step back and see the greater ripple effects require some experience and intuition that can’t always be used to convince people otherwise.
Gold-plated booleans-as-a-service
Earlier quoted context omitted.
> it just reminds me on how feature flags can be misused as application configuration/customization They literally are configuration.
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.
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.