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

71–80 of 104 posts

Re: Show HN: Dorkly – Open source feature flags

#71

Post by keraf »

kageiit wrote: post #30

Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.

At one of my first jobs, the codebase was massive and feature flags were heavily used. My first task given by my boss was to remove flags that have been enabled in all environments for a while. Great and engaging way to introduce someone to a new codebase, it's relatively easy and can be done with little assistance right of the bat, you also get to commit code in your first days and it reduces tech debt making everyone happy.

Been doing that with my new hires in other jobs.

Re: Show HN: Dorkly – Open source feature flags

#72

Post by TheCapeGreek »

vyrotek wrote: post #63
wheresmycraisin wrote: post #62

I have 25 years of coding experience, built two successful businesses, and I have no idea what this thing is supposed to do.

Think of feature flags as remote-toggleable IF statements.

...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 to do within the app rather than add a third party service (and associated cost + potential latency) for it.

Re: Show HN: Dorkly – Open source feature flags

#73

Post by danpalmer »

solatic wrote: post #68
danpalmer wrote: post #37

Earlier quoted context omitted.

It's good to have the current state of all the flags in source control, just like you do for things like infrastructure-as-code. The distinction is that you have a different release process, or build a different artifact, from your main codebase. The codebase you are controlling with flags doesn't change when your flags do. This can be done with separate repos if you want one build per repo, but it doesn't have to be…

If you split feature flags into a different repository, then you're losing the benefit of having everything in a single repository, of having consistency and avoiding situations where your codebase refers to feature flags that don't exist, old feature flags that are no longer checked by the codebase, etc. At this point, your production infrastructure is no longer solely one stateless server + one database, but two da…

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 hit all the sharp corners and put time into solving them).

If you're feature flagging client code (i.e. somewhere you don't control rollouts, like mobile and web apps) that adds another layer of complexity.

While it's nice to have a simple system, having built one from scratch and used very mature feature flagging systems, my experience is that production systems hit almost all the edge cases quite quickly and flagging/experimentation systems are forced to evolve quite quickly to actually account for these issues.

Multi-repo or not isn't really an issue. My previous company had flag config in a separate repo, my current company has a monorepo, it doesn't really make a difference.

Re: Show HN: Dorkly – Open source feature flags

#74

Post by valtlfelipe »

rekoros wrote: post #9

If you’re looking for an open source feature flag option, also check out https://www.growthbook.io/

There is also https://www.flipt.io/ which is open source. I'm currently building https://flaggy.dev/ to be simple and aiming the best user experience, but initially it will not be open source.

Re: Show HN: Dorkly – Open source feature flags

#75

Post by xmcqdpt2 »

TheCapeGreek wrote: post #72
vyrotek wrote: post #63

Earlier quoted context omitted.

Think of feature flags as remote-toggleable IF statements.

...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 legacy reasons and prone to bugs, so we are moving to a centralized feature flag system.

Re: Show HN: Dorkly – Open source feature flags

#76

Post by mrweasel »

snapcaster wrote: post #5

If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been

I'd agree, it seems like the entirely wrong place to put a feature flag. Personally I'd go for either configuration file or database and then have a process for updating the feature flags.

The best implementation I've seen was in a Java project. Features where enable or disabled by either the properties file or the database. If a flag was set in the database, then that took precedence. New features would always be rolled out disabled in the properties file. Then in a controlled window the new features would be enabled for a few minutes and logs would be examined. If everything looked good the feature would then be enabled again. After a few days or weeks, the properties file would be updated to have the feature enabled by default and the flag in the database deleted in a later task.

Re: Show HN: Dorkly – Open source feature flags

#78

Post by zellyn »

yoz wrote: post #42
esafak wrote: post #28

I would expect an open source feature flag solution today to support https://openfeature.dev/

And it does, because it uses LaunchDarkly SDKs: https://docs.launchdarkly.com/sdk/openfeature ... though there are only three officially-supported OpenFeature adapters so far (Java, NodeJS, .NET)

The contributed Go provider seems solid enough, although it's quite opinionated about the exact shape of your attribute map. I just recently documented it carefully in the README :-) https://github.com/open-feature/go-sdk-contrib/tree/main/pro...

Re: Show HN: Dorkly – Open source feature flags

#79

Post by zellyn »

Assuming their (also open source) Relay Proxy[1] can connect to this successfully, the disclaimers about lack of HA might not be too concerning.

We already run a giant pool of relays for our apps to connect to, both to save ingress/egress costs, and to provide a backup if LD blips out for a while.

[Edit: yep, it actually uses the Relay Proxy, in offline mode. See https://github.com/dorklyorg/dorkly/wiki/5.-Architecture]

[1] https://github.com/launchdarkly/ld-relay

Re: Show HN: Dorkly – Open source feature flags

#80

Post by zellyn »

zellyn wrote: post #79

Assuming their (also open source) Relay Proxy[1] can connect to this successfully, the disclaimers about lack of HA might not be too concerning. We already run a giant pool of relays for our apps to connect to, both to save ingress/egress costs, and to provide a backup if LD blips out for a while. [Edit: yep, it actually uses the Relay Proxy, in offline mode. See https://github.com/dorklyorg/dorkly/wiki/5.-Architectu…

LD actually releases a crazy amount of stuff as open source. In addition to the Relay, the server SDKs are all open source too.

In fact, their entire API for flag manipulation and definition (essentially all the operations you can do with their UI, but programmatically) is open too: https://app.launchdarkly.com/api/v2/openapi.json

One could imagine running an OpenAPI → Go/Java/Rust/Python/etc. code generator on their OpenAPI spec, and then gradually implementing their entire API as open source.

Not sure how they would feel about that… although I suspect more usage of an LD-compatible API would only be good for them.

Of course, it makes sense for all those things to be open. The majority of smaller startups they're competing against will have settled on OpenFeature. DataDog too releases some equivalently surprising things as open source: eg. https://vector.dev/

Post reply on HN