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

81–90 of 104 posts

Re: Show HN: Dorkly – Open source feature flags

#83

Post by hbn »

seattle_spring wrote: post #81

Please choose a different name. It could be the most useful product in the world, but no way am I ever advocating something called "dorkly" at work.

I was confused at first because I immediately recognized Dorkly as a YouTube channel that was very popular on YouTube around 2010, they produced comedy animations based on video games though I'm sure the humor isn't as funny as I thought it was when I was 13.

Checking now they have about 4 million subscribers. Probably not gonna be great for SEO longterm.

Re: Show HN: Dorkly – Open source feature flags

#84

Post by theogravity »

icansearch wrote: post #69
theogravity wrote: post #27

Neat! I'll look into integrating this with my feature flag abstraction library: https://github.com/theogravity/feature-manager-wrapper Edit: It looks like it's a backend replacement to LaunchDarkly, but you can still use the LD client from what I'm reading here, so there's nothing for me to integrate here.

Similar to https://openfeature.dev/ ?

Same space but I don't see any integrations listed at all on the site, just SDKs for someone to write their own integration.

Re: Show HN: Dorkly – Open source feature flags

#86

Post by miraantabrez »

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.

This is one of the reasons we built type-safe feature flags at Hypertune. When a developer deprecates a flag, they get type errors everywhere it's still used. This fails the build so they're forced to remove all the flag references, and they get a nice IDE / compiler driven workflow to do that. Otherwise it's easy to leave flag usages around.

Re: Show HN: Dorkly – Open source feature flags

#88

Post by miraantabrez »

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

Agreed that you lose the benefit of "instant updates" if it's always controlled by a PR.

But Git-style version control with history, diffs, branches and pull requests are pretty useful for feature flags and other "app configuration".

Version history and diffs are great for knowing what flag logic changed when + debugging what broke prod.

Branches let you test and preview flag logic changes in your own isolated branch (which you can point the SDK at) — this is a cleaner approach to having a few separate "environments" like development, staging, production which can drift from each other.

Branches are also great for refactoring the schema / structure of all your flags, e.g. deleting a bunch of flags in one go.

Pull requests and approvals are great for when you're making changes to sensitive flags. E.g. you can lock down specific flags.

Pull requests are also great for onboarding nontechnical team members like PMs or sales reps so they can safely make flag changes themselves but require approval from an engineer (at least while they learn to use the system). Empowering nontechnical people is also why a UI is important.

Branching and pull requests are also a great way to prevent conflicts / overwriting other team members flag changes.

So Git-style features are pretty useful, but you also want the UI and you only want to enforce pull requests for specific flags or team members — this is what we built at Hypertune.

Re: Show HN: Dorkly – Open source feature flags

#89

Post by lnxg33k1 »

miraantabrez wrote: post #88
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

Agreed that you lose the benefit of "instant updates" if it's always controlled by a PR. But Git-style version control with history, diffs, branches and pull requests are pretty useful for feature flags and other "app configuration". Version history and diffs are great for knowing what flag logic changed when + debugging what broke prod. Branches let you test and preview flag logic changes in your own isolated branch…

You can get the same comfort of fast updates and history with a feature flag system developed using event sourcing, without having the overhead of git

Re: Show HN: Dorkly – Open source feature flags

#90

Post by drichelson »

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…

It's worth noting that there is no architectural limitation preventing an HA topology: multiple Dorkly servers can be deployed behind one or more load balancers for HA + lower latency where it matters (ie web and mobile apps).

If this is a limitation for anyone I'm happy to work with you on modifying the terraform module to support HA.

Post reply on HN