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?
The example files are put in place by Terraform, so they will get overwritten next time `terraform apply` is run. You can of course change the example flag files as you're kicking the tires or testing out your app, but to really use the system you'll want to create new flags as documented here: https://github.com/dorklyorg/dorkly/wiki/3.-Common-Tasks#add...
These new flags won't be managed by Terraform thus won't get reset to the default values.
I may or may not have grabbed the "LaunchOpenly" github organization name a while back. But I was intending to use it if anyone wanted to write an API-compatible Open Source clone of LD's APIs and flag-editing UI.
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.
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.
The sole reason I like feature flags is that I can quickly toggle off a change if it causes a problem. I'd hate to need to find someone to sign off on restoring service. Anything more than 1 or 2 clicks is just adding precious seconds to an outage. I've worked at places that gave broad implicit approval to developers to toggle away as needed. It worked well.
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.
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.
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.
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}"
LaunchDarkly - ONSITE in Oakland, California.
Not currently hiring remotes workers
Unable to sponsor visas at the moment.
Posting as an engineer who has been working here one year. This is a fantastic team and product. The business is very healthy- not just good growth, but very satisfied customers who are sticking around.
Can you implement analytics on top of those flags, plus a nice UI for nontechnical employees to toggle them faster? If you don't need those, then you probably aren't in their target audience.
Disclaimer: no relation, just playing devil's advocate.
