Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's OK to hardcode feature flags

code.mendhak.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: It's OK to hardcode feature flags

#101

Post by andix »

CRConrad wrote: post #92
andix wrote: post #7

It's even okay to hardcode them into code (not a config/json file). Depending on the build pipeline this is similar to preprocessor flags, and the code will be removed during build. It might be enough to test new features with a limited audience (beta build, test deployments for stakeholders/qa). If done correctly this solution can be easily extended to use a feature flag management tool, or a config file. PS: removi…

> It's even okay to hardcode them into code (not a config/json file). Yes, as I understood it that was what the article was all about.

The article suggests to put them into a config file, and considers it hardcoding. That’s how I understood it at least.

Re: It's OK to hardcode feature flags

#102

Post by CRConrad »

andix wrote: post #101
CRConrad wrote: post #92

Earlier quoted context omitted.

> It's even okay to hardcode them into code (not a config/json file). Yes, as I understood it that was what the article was all about.

The article suggests to put them into a config file, and considers it hardcoding. That’s how I understood it at least.

Ah, yes indeed, seems I'd misread it; sorry.

(Sheesh, WTF is that guy talking about??? Now not only "feature flag" doesn't mean anything any more, but "hardcoded" doesn't either!)

Re: It's OK to hardcode feature flags

#103

Post by maccard »

moltar wrote: post #89
maccard wrote: post #63

Earlier quoted context omitted.

Ah that’s a super nice feature. I’m mostly familiar with AWS who don’t have a neat way of doing this, you end up with a bespoke solution either with lambdas pushing to shared volumes or just polling s3 for updates.

AWS has a native service for this called AppConfig and has agents that can pull and cache flag values so your services only need to make localhost requests.

AH nice, I was not aware of this. Thanks (It is expensive, though...)

Re: It's OK to hardcode feature flags

#104

Post by kiitos »

CRConrad wrote: post #93
kiitos wrote: post #69

Hard-coded feature flags are more commonly referred to as configuration. The primary purpose of feature flags is to provide a way to change system behavior dynamically, without needing a deploy.

> The primary purpose of feature flags is to provide a way to change system behavior dynamically, without needing a deploy. That's not feature flags; it's just ordinary configuration. (Actually, seems many contributions to this discussion get those mixed up. Maybe even TFA itself.)

Ordinary configuration is updated via deployment. Feature flags are updated without deployment. This is the fundamental difference.

Re: It's OK to hardcode feature flags

#105

Post by moltar »

maccard wrote: post #103
moltar wrote: post #89

Earlier quoted context omitted.

AWS has a native service for this called AppConfig and has agents that can pull and cache flag values so your services only need to make localhost requests.

AH nice, I was not aware of this. Thanks (It is expensive, though...)

Expensive?? Really? One of the cheapest services around.

$0.0000002 per configuration request

Re: It's OK to hardcode feature flags

#106

Post by maccard »

moltar wrote: post #105
maccard wrote: post #103

Earlier quoted context omitted.

AH nice, I was not aware of this. Thanks (It is expensive, though...)

Expensive?? Really? One of the cheapest services around. $0.0000002 per configuration request

Depending on when you’re evaluating it’s a per request overhead. You might/provably have multiple flags per request. Compared to a lambda invocation that pushes a config file to every container if it changes, it’s expensive.

Re: It's OK to hardcode feature flags

#107

Post by CRConrad »

kiitos wrote: post #104
CRConrad wrote: post #93

Earlier quoted context omitted.

> The primary purpose of feature flags is to provide a way to change system behavior dynamically, without needing a deploy. That's not feature flags; it's just ordinary configuration. (Actually, seems many contributions to this discussion get those mixed up. Maybe even TFA itself.)

Ordinary configuration is updated via deployment. Feature flags are updated without deployment. This is the fundamental difference.

Eh, what? No, it is -- or at least used to be -- the other way around. Features are what the programmer puts in the actual application code. "Feature flags" are a (new-ish) way of making the transfer from older to newer versions of the application code more manageable for the programmer: If they're actually "hard-coded" (as, say, boolean feature-on-or-off constants) in the application code, they require a deployment of the actual executable; if they're "hard-coded" in the totally new-fangled sense of the word that seems to be emerging here (i.e. not actually hard-coded at all), it may require deployment of a "features configuration file" or such.

Just plain "configuration", though, is how the user sets up their software to work. That's saved in a local configuration file (or the Windows Registry or wherever) under the user's control, and doesn't require any deployment by the developer at all.

Ihan oikeasti, nykynuoriso...

Re: It's OK to hardcode feature flags

#108

Post by fs_software »

It seems like the more deployment friction there is for your project, the more the scale tips toward buy vs build here.

As a solo dev, something lightweight and cost-effective like this is attractive. Deployment is a CLI command or PR merge away.

Would I recommend it for the 200 person engineering org that deploys at most once a week? Probably not.

Re: It's OK to hardcode feature flags

#109

Post by troy55_yort55 »

Sometimes the flag management is more complex than dealign with config - but it's not ideal. Hardcoding flags can be difficult to manage across different environments, regions, customers, etc. Atono.io has flags built right into the stories and it's free for up to 5 users. No limits on the number of flags. Also helps with planning, and bug tracking. Keeps things nice and tidy.

Re: It's OK to hardcode feature flags

#110

Post by uutangohotel »

twisteriffic wrote: post #62
tdumitrescu wrote: post #8

Earlier quoted context omitted.

Seriously. This is one of those cases where rolling your own really does make sense. Flags in a DB table, flags in a json file, all super simple to build and maintain, and 100x faster and more reliable than making the critical paths of your application's request cycle depend on an external provider.

We did this. Two tables. One for feature flags, with name, desc, id, enum (none, defaultToEnabled, overrideToDisabled). One for user flag overrides, with flagId, userId, enum (enabled, disabled). The combination of these two has been all we've ever needed. User segmentation, A/B testing, pilot soft launch etc are all easy.

Would you mind expanding on the usage of enums for the feature flags table? Why not use a boolean?
Post reply on HN