[HN Gopher] Show HN: Dorkly - Open source feature flags
___________________________________________________________________
Show HN: Dorkly - Open source feature flags
Dorkly is a free open source Feature Flag backend for LaunchDarkly
SDKs. It uses simple yaml files stored in GitHub as the source of
truth. Full disclosure: made by a former LaunchDarkly employee +
current fan.
Author : drichelson
Score : 103 points
Date : 2024-06-26 05:28 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hiatus wrote:
| 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)?
| drichelson wrote:
| I have mostly seen developers in charge of changing flags, but
| there is also great value in empowering other roles to change
| flags (One example: sales people can unlock features as they
| sell them).
|
| Thankfully GitHub has an easy web-based Pull Request process.
| It's not as simple as a custom UI, but could be used by non-
| engineers to change flags.
| vosper wrote:
| It's a trusting and non-siloed org that gives the sales team
| access to the repos
| candiddevmike wrote:
| > sales people can unlock features as they sell them
|
| That's a licensing thing, not a feature flag.
| yjftsjthsd-h wrote:
| What's the difference? Either way you're turning on and off
| code that's already in the application. The only difference
| I can immediately see is that some people do feature flags
| as being on or off for the entire application instance, but
| I'm pretty sure you can do A/B testing with them at
| arbitrarily fine granularity and still count as a feature
| flag.
| yoz wrote:
| Not always. The most common counter example is beta
| features which customers opt into, controlled by the
| product team. It's too early for that to be part of the
| license, especially because pricing often hasn't been
| decided yet.
|
| But there's also a surprisingly common situation with big
| customers who want to limit and control certain UI updates
| so they can ensure that employees are trained
| appropriately.
| shagie wrote:
| There are many different types of toggles of functionality.
| Not all of them are enabling code features. Well, they
| _are_ but the _why_ they are is what is at issue.
|
| But it's all the same _code_ under the covers. The
| functionality of what is enabled encoded into a license key
| - that 's the same type of functionality as "does this
| deployment allow people to sign up by email" or "has this
| deployment enabled the super secret power user test
| functionality?"
|
| But that's all under "if dataSource.toggle then
| {something}"
|
| https://martinfowler.com/articles/feature-toggles.html
| mikejulietbravo wrote:
| I'm kind of surprised they haven't already built this into the LD
| core
| snapcaster wrote:
| 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
| alexchamberlain wrote:
| I think the idea is that it's a separate flags repo?
| snapcaster wrote:
| Can you say more? I think i'm missing the point, in my mind
| that would make it even worse because you have all the
| problems I mentioned + merge conflicts being a possibility
| Pet_Ant wrote:
| Well I don't think you are doing active development on your
| flags repo. I think it's just using Git as a database for
| the what are your current feature flags.
| irjustin wrote:
| One repo is actual flags control-like-database.
|
| So instead of controlling flags from a website, you get the
| benefits of git merge, PR's, reviews, documentation etc
| without having to rebuild it.
|
| I like the concept since it brings accountability. But it's
| just a need that larger orgs have, but by that point have
| likely internally built a flag system and so transitioning
| is difficult.
| Osyris wrote:
| We do this at my company and another huge benefit is the
| ability to test config at a particular point in time. You
| can even git bisect to find which flag flip caused a
| regression.
| drichelson wrote:
| Correct: the flags live in a separate repo.
| drichelson wrote:
| The PR is optional, but governance often requires documented
| peer approval for all production changes.
|
| Flag changes can be pushed directly to the main branch with the
| correct repo permissions. When using the GitHub UI this
| involves just a little bit of typing and a few clicks.
|
| >might as well just change the code at that point
|
| If changing the code, running tests, building, and deploying is
| quicker and less risky then yes that makes more sense.
| wewtyflakes wrote:
| This seems like a reach. A nice benefit of having these
| server-owned configuration flags with a slick UI (like
| launchdarkly) is that they can be modified by people on the
| fly, and by people who may not even be engineers (like
| product managers). I imagine, that if the ask is that they
| instead get GitHub permissions, make a PR, wait for a review,
| etc, then perhaps you are not competing with launchdarkly.
| Though, having Git controlled server-owned configuration is
| still nice regardless.
| __MatrixMan__ wrote:
| If not a PR review, how would you propose people should build
| consensus around:
|
| > I'm about to do this thing to mitigate the issue, does it
| look like the right thing?
|
| It doesn't need to be a code change, can just be a flags
| change, but if it's a change at all then why not pin it to a
| commit so that rolling it back is easy and so that the commit
| sha can be an indicator of which flags are where.
| rekoros wrote:
| If you're looking for an open source feature flag option, also
| check out https://www.growthbook.io/
| peab wrote:
| I introduced feature flags at my last company, and ended up
| choosing growthbook. I love how compute experiment buckets with
| local hashing, so you don't have to make roundtrip server calls
| to get flag values.
| socksy wrote:
| In a similar vein there's also Unleash with a similar open core
| model https://github.com/Unleash/unleash
| ripperdoc wrote:
| 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?
| cqqxo4zV46cp wrote:
| You aren't. This doesn't mean that feature flags are useless or
| not worth it, but there's no silver bullet. It is exactly as
| hard an engineering problem as it sounds.
| viraptor wrote:
| 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.
| waynepan wrote:
| I'm also unrelated to Dorkly but I'm a big believer in feature
| flagging. It's key to moving fast as an engineering/product
| team.
|
| be happy to walk you through how we use it. Shoot me an email
| if you want to chat. wayne at inaccord.com
| theogravity wrote:
| 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.
| esafak wrote:
| I would expect an open source feature flag solution today to
| support https://openfeature.dev/
| kageiit wrote:
| 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.
| _corym wrote:
| My team leverages feature flagging heavily. Developers want to
| clean them up but product doesn't prioritize the tickets, and
| it creates more burden for QA as well having to do a full
| regression test.
| millerm wrote:
| Then that is simply a bad lead on the team. "Do your job." (Not
| you)
| dangoodmanUT wrote:
| Naming
___________________________________________________________________
(page generated 2024-06-27 23:00 UTC)