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

Show HN: Dorkly – Open source feature flags

github.com

Post reply on HN
Print view View original

101–104 of 104 posts

Re: Show HN: Dorkly – Open source feature flags

#101

Post by TheCapeGreek »

xmcqdpt2 wrote: post #75
TheCapeGreek wrote: post #72

Earlier quoted context omitted.

...which still begs the question - why does it need to be an entirely different service? Probably answering my own question, but the main reason I can think of would be if your app doesn't have some kind of business admin panel capability. I suppose my bias is also that in my sphere of web dev, we build these business panels pretty frequently, so feature flags and a UI for toggling them is something that makes sense…

You mean an admin panel on a server application, right? At my current job, I'm on a platform team that supports hundreds of applications. Each of them have their own admin panels. However, there are settings that apply to all of them in our library code. For those, we use feature flags, and they are loaded from a network service, environment variables, code and config files. The overriding logic is complicated for le…

Fair, that makes sense. Not a very common use case I think unless you're talking more about heavy use of microservices that need a feature flag across the entire suite.

Re: Show HN: Dorkly – Open source feature flags

#102

Post by hinkley »

hinkley wrote: post #56
viraptor wrote: post #26

Earlier quoted context omitted.

You need to organise your features in a way that these are not a problem. Need different dependencies - load both. Need a different schema - write both versions, drop old later. Need new services/APIs - feature flip only the user-visible one. The flags are really useful for things like enabling just a fraction of traffic, or ensuring you can switch a feature off much quicker than a full deploy would take.

Everyone laughs when I say this but pull up a thesaurus. When you change the semantics of a thing, you have to change names to have old+new live at the same time. Don’t trust your mastery of English ( especially if it’s your second language). There’s a synonym out there that describes the new behavior as well or even better.

Exhibit A.

Re: Show HN: Dorkly – Open source feature flags

#103

Post by danpalmer »

solatic wrote: post #100
danpalmer wrote: post #73

Earlier quoted context omitted.

With one repo you still have versions of this problem – have the flags been deployed as config to the flag system before the server build, has the server build removing usage rolled out fully by the time you remove the config. Using an RDBMS is an option, but makes scaling harder, you still need an audit trail, review processes, etc, so you eventually end up building a source control system on top of it (assuming you…

> Using an RDBMS is an option, but makes scaling harder Modern Postgres scales vertically quite well on modern hardware. > you still need an audit trail, review processes, etc, But you need this anyway for the RDBMS in your architecture. You need an audit trail for when engineers need to get into the production database, and to show that their changes passed review, etc. My point is, if you anyway need to build this…

Many services won't need an RDBMS, and for those that do there's a difference between the control plane of an application (development and releases), and the data plane (users using the service).

This is a complex and nuanced topic, but on my previous team of ~6 where we built a custom solution, we decided against using an RDBMS for multiple reasons, and on my current team where we use the same flagging system across 15 or so >1m requests per second services, there's no way it would work for us. If it works for your use case, that's great! But my advice for anyone else reading would be to put a lot of effort into considering the options as it's hard to change later and has significant impact on how the flagging system is used.

As for whether to use a commercial platform... my preference is probably to build my own with what I need in a system that I can modify as needed, or a commercial platform if there's one ready to go at a good price with the right feature set. I probably wouldn't use an existing open source option here unless I was forking it and treating it as my own from then on, as I find these things need flexibility and customisation. I've yet to see a great open source option.

Post reply on HN