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?
Show HN: Dorkly – Open source feature flags
21–30 of 104 posts
Re: Show HN: Dorkly – Open source feature flags
#22[deleted]
Re: Show HN: Dorkly – Open source feature flags
#23Not 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…
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.
Re: Show HN: Dorkly – Open source feature flags
#24If you’re looking for an open source feature flag option, also check out https://www.growthbook.io/
In a similar vein there's also Unleash with a similar open core model https://github.com/Unleash/unleash
Re: Show HN: Dorkly – Open source feature flags
#25If 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
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…
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.
Re: Show HN: Dorkly – Open source feature flags
#26Not 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…
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.
Re: Show HN: Dorkly – Open source feature flags
#27Neat! 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.
Re: Show HN: Dorkly – Open source feature flags
#28I would expect an open source feature flag solution today to support https://openfeature.dev/
Re: Show HN: Dorkly – Open source feature flags
#29Not 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…
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
Re: Show HN: Dorkly – Open source feature flags
#30Feature 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.