81–90 of 189 posts
Earlier quoted context omitted.
Hi! One of the engineers from the Flagship team here, app-scoped tokens are WIP.
That sounds like the product is not finished and should not be released?
I've never understood feature flags. How are they fundamentally different to a Boolean in a database?
Feature flags are often ridiculously over engineered. Check a config, bdd value, env var to dynamically go one path or the other. That’s all, you must either have a small feature or refactor the code to easily switch at a high level. If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services. Or if you have many features…
I've never understood feature flags. How are they fundamentally different to a Boolean in a database?
Cloudflare themselves even uses them internally as such, by shipping new features/builds to their free customers first, and then progressively larger customers after a settling period.
Feature flags can also be randomly turned on, for a sort of fuzz testing. Don't think of them just as 'new things' - it could be 'changed behavior'.
I guess you could think of them as a boolean on every client but they're generally not implemented that way.
I've never understood feature flags. How are they fundamentally different to a Boolean in a database?
I've never understood feature flags. How are they fundamentally different to a Boolean in a database?
That’s all it is. This only exists to lock you into cloudflare even more.
Oh, that's right, you just spouted a "big company bad" mantra without bothering to read the article. Look, I know saying RTFA goes against the HN guidelines, but the amount of increasingly lazy spew i see from folks (or bots) who haven't bothered to read the article is so tiresome and annoying.
I've never understood feature flags. How are they fundamentally different to a Boolean in a database?
Never underestimate the power of a zero-network-hop abstraction over f(feature_name, context). And context can be extremely tailored to your niche: specific inventory, from a specific supplier, for a specific user of a specific B2B client of a specific business model subtype, who should or shouldn’t see certain features on that specific inventory at certain times. When you can write your own logic, and just run this…
It doesn't have to be sophisticated and they don't need to implement it themselves. They piggy-back on OpenFeature where the client libraries have a simple targeting rule evaluation engine integrated.
Earlier quoted context omitted.
There's an argument to be made for being able to turn on a feature for a certain segment (e.g low revenue users in Italy) so you can see what the business/performance impact is. Ofcourse you don't want users to lose the feature once they exceeded your revenue threshold or cross the border so you'll need to implement some kind of tracking. Your analytics and error tracking also needs to communicate with the feature fl…
Enterprise software is full of this kind of stuff. Half our customers are on year old UI's because they don't want to re-up contracts yet. That is, features are contractual and when you've only got 50 customers but they're all paying high 6 figures does anyone really care about feature flag complexity?
"The customer would like the main page blue and another one the red". Would it be feature flag for you?
I've never understood feature flags. How are they fundamentally different to a Boolean in a database?
To me the main appeal of feature flags is that they allow to work on large features that often require months and many commits to finish in a main branch. This, at least to me, results in a more lightweight and more iterative development process. This contrasts with maintaining a separate branch, with perhaps separate deployment target for a large in-development features.