Principles for building and scaling feature flag systems • Hacker News Board

Re: Principles for building and scaling feature flag systems

#111

Post by zellyn » Tue, Sep 26, 2023, 4:17 PM UTC

sporkland wrote: post #109

zellyn wrote: post #25

Earlier quoted context omitted.

Sadly, this is a battle you are destined to lose. I have almost completely given up. The best you can aim for is to use feature flags better rather than worse. - Some flags are going to stay forever: kill switches, load shedding, etc. (vendors are starting to incorporate this in the UI) - Unless you have a very-easy-to-use way to add arbitrary boolean feature toggles to individual user accounts (which can become its…

We have an interesting hybrid between the two that I'd like your take on. When we release new versions of our web client static assets we have a version number that we bump that moves folks over to the new version. 1. We could stick it in a standard conf system and serve it up randomly based on what host a client hits. (Or come up with more sophisticated rollouts) 2. Or we can put it as "perm" conf in the feature fla…

1) If you do Slack, then I recommend you join the #openfeature channel on the CNCF Slack. The inviter is here: https://communityinviter.com/apps/cloud-native/cncf

2) The downside of rolling it out based on host is that you could refresh your page, hit a different host, and see the UI bouncing back and forth between versions. As long as you always plan to roll things to 100%, this is the perfect use case for a feature flag.

Re: Principles for building and scaling feature flag systems

#112

Post by kiitos » Wed, Sep 27, 2023, 2:37 AM UTC

zellyn wrote: post #108

kiitos wrote: post #94

Earlier quoted context omitted.

> Are flags evaluated in-memory, locally? (Hopefully!) This seems like a MUST rather than a SHOULD, right?

I would have thought so. But flagsmith apparently does primarily server-side eval. And even OpenFeature has `flagd`, which I guess is a sidecar, so a sort of hybrid approach. And LaunchDarkly's Big Segments fetch segment inclusion data live from redis (although I believe they then cache it for a while).

If this is the case, then flag evaluation can't possibly be part of any kind of hot loop, right?

Re: Principles for building and scaling feature flag systems

#113

Post by zellyn » Wed, Sep 27, 2023, 2:04 PM UTC

kiitos wrote: post #112

zellyn wrote: post #108

Earlier quoted context omitted.

I would have thought so. But flagsmith apparently does primarily server-side eval. And even OpenFeature has `flagd`, which I guess is a sidecar, so a sort of hybrid approach. And LaunchDarkly's Big Segments fetch segment inclusion data live from redis (although I believe they then cache it for a while).

If this is the case, then flag evaluation can't possibly be part of any kind of hot loop, right?

¯\_(ツ)_/¯

I guess see if dabeeeenster is monitoring this thread anymore and ask them?

Re: Principles for building and scaling feature flag systems

#114

Post by gastonfournier » Thu, Sep 28, 2023, 7:01 PM UTC

tantalor wrote: post #106

gastonfournier wrote: post #102

Earlier quoted context omitted.

AFAIK, it'd only open a PR if the flag is fully enabled and has some heuristics to determine when it's safe to remove. Honestly, I haven't tested it but I'm curious to know if someone had either good or bad experiences. If all the PRs are instantly rejected, that would be a bad sign, but I couldn't find someone who effectively used it. I mean, it's been around for a while but it didn't spread out, so that already giv…

If the cleanup only happens if the flag is not used, then the "expiration date" is basically meaningless. You can either delete it or you can't. Who cares if it's expired or not.

I think expires is just a signal for a feature that should "potentially" be removed. I believe it's a good way to focus on the ones you should pay attention to. But, it might be cool if you could say "Yes, I know, please extend this for another period" (or do not notify me again for another month)

Re: Principles for building and scaling feature flag systems

#115

Post by gingerrr » Mon, Oct 02, 2023, 11:02 PM UTC

flitzofolov wrote: post #87

gingerrr wrote: post #44

Earlier quoted context omitted.

Definitely getting strong uncanny valley prose vibes. Hard to tell if it's generated or written in an attempt to be as plain English as possible, but either way feels strangely vacuous for a technical opinion piece. There's no writer's voice.

It's not really an opinion piece is it? It's docs. The language seems appropriate for articulating principles.

Whoops I missed this reply!

I think it's absolutely an opinion piece - defining specific items as principles by definition means expressing opinionated ideas about the relative priority of those items over others. Also, imperative mood contains value judgment, which is inherently opinion-based (e.g. "Never expose PII"). Making arguments for why you should or should not do things requires expressing opinions about relative importance, weight etc.

If this were instead an article describing what feature flags are, or one performing a survey of various approaches to building/scaling them, I think the lack of voice is just fine - that's dealing in statement of fact. But this article mandates and implores and exhorts - the value judgments inherent in that pathos are empty without genuine authorship.

Also I'm not saying the lack of voice is bad even for conveying meaning or teaching - more that it is jarring and uncanny to read imperative claims in an empty robotic voice devoid of ethos.

Finally, I also might be biased by my first documentation love, the zeromq guide, which is an extremely-strongly-opinionated piece of docs that does its job exceptionally well. I think when writing about how or why, a strong writer's voice is more compelling. This article stretches past just the what into those other question words, so its seeming lack of authorial authority falls flat to me.

Thanks for giving me an excuse to blabble lol.