91–100 of 104 posts
I have 25 years of coding experience, built two successful businesses, and I have no idea what this thing is supposed to do.
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.
In my experience engineers usually want to remove the outdated flags but product does not prioritize that work.
The best companies I've been at where those where product and engineering really operate as one team.
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.
Which yaml files is one supposed to edit to actually modify the flags?
Earlier quoted context omitted.
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.
For instance, here are is the repo for contributed Providers in Go: https://github.com/open-feature/go-sdk-contrib/tree/main/pro...
And here is LaunchDarkly's official Java OpenFeature provider: https://github.com/launchdarkly/openfeature-java-server
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.
Fair point. I’m open to suggestions for a new name :)
Earlier quoted context omitted.
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.
Random question while you're paying attention here. In the example repo, I was unable to find a file that _didn't_ say "This file is managed by terraform. Do not edit manually." Which yaml files is one supposed to edit to actually modify the flags?
This is good feedback. I'll clarify the comments
So feature flags without the UI?
Earlier quoted context omitted.
At the risk of sounding like a broken record, I think this is a problem that is compatible with Kanban and incompatible with Scrum. The end of sprint encourages people to mark a task as done that still has several steps and about eight business days before it’s “Done”. But WIP limits in Kanban could be tweaked to account for this and I believe still provide the correct sort of pressure for you to finish what you star…
As someone whose current team process is Kanban and a previous team were also, tech debt like this still inevitably piles up. Sure maybe you can squeeze some time in but even getting a week to spend solely on cleanup is rare, if it comes up at all.
Admittedly, there’s still a gap there where a toggle may be needed until the end of an initiative (an Epic in Scrum terms) but that’s going to be at least an order of magnitude, and likely 2 orders, fewer toggles to deal with.
When the order of magnitude changes so does the solution.
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…
In most such cases you have several instances of your backend running in parallel for scaling and redundancy and when making a release, instances of several versions run concurrently. So you don't have a "atomic upgrade" available
With multiple services coordinating upgrade is even harder.
Patterns like expand-contract helps you manage this..E.g. first add the new endpoint to server, then move clients over, then remove old endpoint.
So..feature flags is just a way of dragging this process over longer time period, and roll over % of traffic. Instead of coupling changes to service releases you roll over using config.
Used them a lot in backend to backend, backend to DB etc scenarios, has been hugely useful to us and would never work without it.
But, of course depend on context what you are doing.
Earlier quoted context omitted.
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…
Modern Postgres scales vertically quite well on modern hardware.
> you still need an audit trail, review processes, etc,
But you need this anyway for the RDBMS in your architecture. You need an audit trail for when engineers need to get into the production database, and to show that their changes passed review, etc. My point is, if you anyway need to build this for your RDBMS, then you can build on top of that for your feature flag system if you throw that into your RDBMS as well.
> 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.
I think that's more an argument to use a commercial feature flag platform (like LaunchDarkly) instead of a FOSS option. A commerical platform is anyway what I would prefer to recommend! But, with the context of "choose a FOSS option", it seems to me like building on top of RDBMS, rather than GitOps, makes more sense.