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

81–90 of 111 posts

Re: It's OK to hardcode feature flags

#81

Post by maccard »

withinboredom wrote: post #73
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.

If you are using kubernetes, you can mount the secret/ConfigMap as a volume and it will be updated automatically when changes occur. Then your application merely watches the file for updates.

Being on AWS, using EKS feels like overkill when you're talking $75/month just for having it managed by AWS. This doesn't work with ECS, unfortunately, or if you're just running docker on EC2.

Re: It's OK to hardcode feature flags

#82

Post by eqvinox »

> Simply start with a simple JSON file, read it in at application startup,

That's not what I'd call hardcoding, it's a startup-time configuration option. Hardcoding is, well, "hard coding", as in changing something in the source code of the affected component, in particular with compiled languages (with interpreted languages it the distinction is a bit mushy.)

And then for compilation there is the question whether it is a build system option (with some kind of build user interface) or "actual" hardcoding buried somewhere.

Also, there is a connection to be drawn here to loadable/optional software components. Loading or not loading something can be implemented both as startup-time or runtime decision.

Re: It's OK to hardcode feature flags

#83

Post by adamredwoods »

dlevine wrote: post #75

I have found feature flagged rollouts to be one of the biggest advances in fairly recent software development. Probably too much to say about it in a comment, but they massively de-risk launches in a number of important ways, both in being able to quickly turn a feature off if it has unintended consequences and being able to turn it on for a very specific set of users. With that said, I think that LaunchDarkly and th…

If one of these services was able to catalog commits with the FF, that's be worth gold (wink wink Launch Darkly).

Re: It's OK to hardcode feature flags

#84

Post by simonw »

jitl wrote: post #26
Kwpolska wrote: post #10

Earlier quoted context omitted.

> using an (often expensive) feature flags as a service platform I have no idea why anyone would actually do that in real life. Feature flags are something so trivial that you can implement them from scratch in a few hours, tops — and that includes some management UI.

Often these 3rd party offerings are feature flags PLUS experimentation with user segmenting. Depending on the style of software you build, this can be extremely valuable; it’s very popular in the SaaS market for a reason. Early on at Notion we used simple percent rollout in Redis, then we built our own flag & experimentation system, but as our needs got more complex we ended up switching to a 3rd party rather than de…

That path sounds very sensible to me.

Re: It's OK to hardcode feature flags

#85

Post by hirsin »

fizx wrote: post #45
hirsin wrote: post #11

Earlier quoted context omitted.

You'll still be building management UI over their system (it doesn't understand or validate actor types, tenants, etc, so you have to do that.). But at high throughput, you might want something with dedicated professional love. Ten thousand feature flags, being checked at around 2 (or 200) million RPS from multiple deployments... I don't want to be the team with that as their side project. And once you're talking a t…

The scale is easy in practice, cause you outsource to a CDN. But everything takes time and has opportunity cost.

Maybe we've worked with different FF systems, but anything that involves a call more expensive than an RPC would be lethal to request latency. Calling out to a CDN forty five times per inbound request would be... Infeasible

Re: It's OK to hardcode feature flags

#86

Post by cyberax »

PaulHoule wrote: post #71
dasil003 wrote: post #52

Earlier quoted context omitted.

I'm confused. Are you saying this ironically or have you literally pitched management with the risks of using your product?

I developed an open source "user management system" circa 2001 which I used on several sites, including one that had 400,000+ users, a famous preprint archive and the web site of a county-level green party. It was patterned on what sites like Yahoo and Amazon had at the time, did email verification and numerous things that were a hassle to implement, had great screens for the administrators, all of that. I couldn't g…

There's such a thing as being too early.

My university had a great shared browser bookmark management system, even with a basic discussion support for them. In 1998. It was not super popular because people just didn't have that many links to share, eventually it fell offline and got accidentally deleted in 2001.

Re: It's OK to hardcode feature flags

#87

Post by bradgessler »

I built a Ruby library for feature flags that’s completely hardcoded.

In a rails app you have an ./app/plans folder with Ruby files, each command containing a class that represents each feature in a plan.

There’s code examples at https://github.com/rubymonolith/featureomatic if you want to have a look.

I’ve used it for a few apps now and it’s been pretty useful. When you do need plug a database into it, you can do so by having the class return the values from a database.

Re: It's OK to hardcode feature flags

#88

Post by fizx »

hirsin wrote: post #85
fizx wrote: post #45

Earlier quoted context omitted.

The scale is easy in practice, cause you outsource to a CDN. But everything takes time and has opportunity cost.

Maybe we've worked with different FF systems, but anything that involves a call more expensive than an RPC would be lethal to request latency. Calling out to a CDN forty five times per inbound request would be... Infeasible

A background thread long polls the CDN, updating a local hashmap on change.

Re: It's OK to hardcode feature flags

#89

Post by moltar »

maccard wrote: post #63
superb_dev wrote: post #51

Earlier quoted context omitted.

We keep a JSON blob in Google Secret Manager for our flags. The service running in the container will reload the secret anytime it changes

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.

Re: It's OK to hardcode feature flags

#90

Post by jasonkarns »

Spivak wrote: post #37
hirsin wrote: post #11

Earlier quoted context omitted.

You'll still be building management UI over their system (it doesn't understand or validate actor types, tenants, etc, so you have to do that.). But at high throughput, you might want something with dedicated professional love. Ten thousand feature flags, being checked at around 2 (or 200) million RPS from multiple deployments... I don't want to be the team with that as their side project. And once you're talking a t…

But it's not a side-project in most implementations it's part of the app itself.

Side project means it’s not that team’s primary focus.
Post reply on HN