Can this do anything spring cloud config can‘t do?
Show HN: Feature Flags Backed by Git
21–30 of 46 posts
Re: Show HN: Feature Flags Backed by Git
#22I like this design choice!! Wondering, what will be the biggest drawback pop in your head compared to traditional DB config or feature flags solution?
Re: Show HN: Feature Flags Backed by Git
#23Can this do anything spring cloud config can‘t do?
This is my question. If your flags are in your repo, what is functionally the difference from just having them be variables in your code somewhere.
"Feature Flags that live inside your code" - That's just variables, no?
Re: Show HN: Feature Flags Backed by Git
#24Very glad to see percentage-of-users experiments, that's where it falls short to simply deploy/rollback the new version.
Re: Show HN: Feature Flags Backed by Git
#25This post comes at a great time! I've been wondering what folks prefer - git or DB backed configs and feature flags. How do you decide to go with one or the other? What do you guys do when GitHub inevitably has an outage?
Nice thing about git feature flags: the state of your system is all in one place. It changes only when you do a code release, which includes feature flag values, or an infrastructure release. You can easily see, just off git history, when the state of the system changed (and what changed), which makes incident debugging much easier. With DB feature flags, there's one more source of truth for changes to production inf…
Maybe I’m not fully understanding what this product is doing. For something like configs/feature flags, it imo should be dynamic.
I was thinking that git (in a separate repo from main code) would be used to store the changes to configs, but then you would still need a system that tails the git changes and distributes them to clients.
That’s the way config serving was done at Facebook - a mercurial repo with all configs and tooling to edit configs which creates mercurial commits. Then, the mercurial repo is continuously tailed and values are saved to ZooKeeper, and then client libraries read config data from zookeeper / subscribe to updates / etc.
Re: Show HN: Feature Flags Backed by Git
#26Earlier quoted context omitted.
Nice thing about git feature flags: the state of your system is all in one place. It changes only when you do a code release, which includes feature flag values, or an infrastructure release. You can easily see, just off git history, when the state of the system changed (and what changed), which makes incident debugging much easier. With DB feature flags, there's one more source of truth for changes to production inf…
Maybe I’m not fully understanding what this product is doing. For something like configs/feature flags, it imo should be dynamic. I was thinking that git (in a separate repo from main code) would be used to store the changes to configs, but then you would still need a system that tails the git changes and distributes them to clients. That’s the way config serving was done at Facebook - a mercurial repo with all confi…
This is actually how it works.
Flipt is live tailing the repository and serving this dynamically to the clients.
The repo with flag configuration can be solely for flags, or alongside other infra configuration on in more of a monorepo. You decide how you want it setup.
Obviously if it is alongside code, you may to contend with CI in order to validate a change. But with the rules in CI or other monorepo tooling, what runs and when can adjust this behavior to improve time for configuration to become live.
Once a configuration change is integrated into a target branch in the repo, then it becomes readable for Flipt and servable once fetched.
Re: Show HN: Feature Flags Backed by Git
#27[dead]
Re: Show HN: Feature Flags Backed by Git
#28Can this probably be done with GitHub Actions and GitHub Pages without any 3rd party platform (just no UI)?
Flipt itself is open source and includes the git backend. So if that works for you, great!
In our experience a lot folks came and said… but the ui is so important for us to be able to use a feature flag tool.
Re: Show HN: Feature Flags Backed by Git
#29Can this do anything spring cloud config can‘t do?
This is my question. If your flags are in your repo, what is functionally the difference from just having them be variables in your code somewhere. "Feature Flags that live inside your code" - That's just variables, no?
Feature flag state is still served dynamically through Flipt. Your code doesn’t have to redeploy for the changes to “become live”. That’s the main benefit.
Means you can experiment and target different cohorts with variants of your app without restarting processes everywhere.
Re: Show HN: Feature Flags Backed by Git
#30I like this design choice!! Wondering, what will be the biggest drawback pop in your head compared to traditional DB config or feature flags solution?
Complexity of initial implementation was certainly one, as we developed it. It’s not the most well trodden path for this kind of problem (well trodden for other kinds of apps). Obviously it lacks things like relations and schema, that we have to build on top of data in flat files.
One thing is that running Flipt open source on your infra, means running replicas all sourcing from the same Git repo. They currently polls for updates and this means eventual consistency comes into play when you scale. We have plans to help mitigate that with cloud though (pushing updates from cloud to your self hosted runners).