June 26th, 2024

Show HN: Dorkly – Open source feature flags

The GitHub repository hosts backend components for Dorkly Flags project. It includes Go code for GitHub Actions, converting YAML files for ld-relay. Dockerfile and related files are available for image creation. Contact for details.

Read original articleLink Icon
Show HN: Dorkly – Open source feature flags

The GitHub repository provided contains the backend components for the Dorkly Flags project. It features Go code designed to operate within GitHub Actions, converting YAML files into a format compatible with the ld-relay appliance. The repository also includes a Dockerfile and associated files essential for constructing the image utilized in the operational backend service. For further information or specific inquiries, please don't hesitate to reach out for assistance.

Link Icon 19 comments
By @snapcaster - 4 months
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

By @kageiit - 4 months
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.

By @rekoros - 4 months
If you’re looking for an open source feature flag option, also check out https://www.growthbook.io/
By @zellyn - 4 months
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

By @ripperdoc - 4 months
Not directly related to Dorkly, but we've implemented feature flags (with our own system) and found them not super-useful and was hoping for more - but we may be doing it wrong. I can certainly see feature flags working well for us when activating e.g. new mostly UI-related features, but when many services and APIs need to change in unison for new features it seems a lot harder to use feature flags in practice. Then it goes beyond just putting new feature code behind conditions, as you might need to load different dependencies, offer different version of server APIs, run on different database schemas, etc. But maybe we are missing something?
By @esafak - 4 months
I would expect an open source feature flag solution today to support https://openfeature.dev/
By @wheresmycraisin - 4 months
I have 25 years of coding experience, built two successful businesses, and I have no idea what this thing is supposed to do.
By @hiatus - 4 months
I like the idea of the flags being managed via normal change-management processes. In your experience, is it primarily developers in charge of enabling/disabling flags or have you seen responsibility diffused across departments (marketing, sales, etc)?
By @drichelson - 4 months
Author here. I'm paying more attention to GitHub than the comments here so please feel free to chime in there or ask any questions: https://github.com/dorklyorg/dorkly/discussions/40
By @alienchow - 4 months
Nice, thanks for sharing. I've been looking for an alternative to CDPush (Google's internal version controlled config push).

Unaudited, untracked web UI based feature flagging has been my peeve with the other solutions. I'm surprised all the feature flagging solutions out there don't have this as a default. The next step would be to use an artifact versioning repository to decouple from S3.

By @Lukas1994 - 4 months
Does this generate type-safe code? We ended up using https://www.hypertune.com/ to solve that problem.
By @seattle_spring - 4 months
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.
By @gedw99 - 4 months
By @theogravity - 4 months
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.

By @mikejulietbravo - 4 months
I'm kind of surprised they haven't already built this into the LD core
By @jerrygoyal - 4 months
i don't think most businesses need third party solution for feature flags. Just create an api and send config.
By @byyll - 4 months
So feature flags without the UI?
By @dangoodmanUT - 4 months
Naming