entitlements is a huge one. Sooooo many orgs are in an absolute rats nest of confusion because half their entitlements are in something like an auth system, half are in something like billing and the third half is hacked into feature flags.
One particular pain point is that finance or something "do users with access to feature X retain better and it's super hard to figure out.
My overall feel is that developers are trying to solve a problem and that it turns out the configuration is as fundamentally as important as the software itself. I define "dynamic configuration" as "a key value store which takes context and has rules based system to give you a value". This primitive turns out to be extraordinarily useful and powerful. Rather than try to split it into N different systems, each custom / don't have telemetry / aren't available to all services SDKs. What if you have ONE BIG CONFIG system that really does a bang up job.
By focussing on one terrific system, you can put all your eggs into the basket of making that reliable / comprehensible / flexible / strict.
The one on your list that I think DOESN'T belong would be permission checks at user level. The N of that is not a good fit for config (though when you look at the facebook paper, it's pretty wild how they've scaled it (but it doesn't do permissions afaik)).
Strongly agree that Config & FeatureFlags are two different things. But as I've tried building tools in the space: man is it difficult to really nail down what the difference is.
For Quonfig I landed on:
- Data model wise they are identical. Flags and configs can both be targeted. They can both use segments. They can both do partial rollouts. They can both have the same range of values (bool/number/duration/json/json-w-schema/etc)
- Its fine to use Flags for your Experiments/AB Tests, but that's just the "allocation engine". The rest of experimentation is the exposure tracking and goal tracking. Those ought live in your product analytics stack, because they are really just events. But its helpful to have a single place (flags) for the experiment allocation because then you can re-use segments for things like hold out groups / and just general targeting.
- The only real difference is that Flags are intended to be ephemeral and configs are intended to be permanent. A good UI should show you how long a flag has been alive and help you clean it up (or convert it to a config) if it's been true for everyone for too long.
- The use cases are different enough that it's worth keeping them in two separate UI.
One way I’ve thought of it is to ask what happens if the function is blocked, how is it enabled mechanically and why would that be changed? Once you answer these, you start to see the groupings more clearly, I’ve found.
I am on my second feature flag startup, but I also somewhat agree with this.
Every project should have flags, but many projects need just the basics and a service is overkill.
Rolling your own JSON still feels like something we ought avoid though. Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.
I’ve tried to incorporate this lowest common denominator into https://quonfig.com Use it totally free & open source as SDK, and it’s just loading JSON that you can track in git. Agents love it, hot reloads, SDK in lots of languages. But vs rolling your own you’ve got a lot of headroom on the design. A bunch of targeting operators. Segments etc. And then if you do want to get a nice UI / delivery network for real time updates, then you can use the paid side of things.
Your second startup dedicated to feature flags? Aren't these just some booleans with optional support to toggle them at runtime? Maybe I've just not been in the right domain, but I would have thought that if someone's use of feature flags is so complicated that they need a whole company to support it then they've massively overengineered their code.
The author literally spells out why this isn't always the case:
> Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.
First one got acquired. But also I wish I'd built it differently from the start (git based, other lessons learned), so started over.
It's true that it's a pretty simple thing, but you do want them to be of the utmost level of reliability. Its ideal if you can use feature flags & dynamic config (which I think of as the same problem) right at boot time. But then of course you have an external dependency to booting you app. So the reliability angle becomes imperative. So I do think the SaaS can play a good (or bad) role in overall reliability vs something you implement in house.
The other major advantage is telemetry. Once you have things toggling on and off, immediately engineers will get confused about whether something is on or off and why. Basic internal apps usually don't have any good telemetry / debugging. So a good SaaS should give you all kinds of ways to ensure that you can see what context is being passed around to the SDK to do their eval. Sanity checking etc.
My og experience was at HubSpot where we used the hell out of dynamic config. Once you get used to things like instantly targeting debug log levels for a single class to a single org its hard to go back.
Also not mentioned here was the map. A real physical map and then shooting the sun to get your latitude. I loved this. Being truly lost in a game was wild.
With the printed map and some game experience you will find your way around pretty easily. What really develops if you play the game multiple times is optimising routes, e.g. by postponing the pickup of a relative until you have another good reason to sail to a remote place. Also you get really allergic to sailing downwind over long distances. Then the speed of the fleet is determined by the slowest ship and damaged ships sail even slower not only in battle. While we enjoyed having fleets with big battleships with lots of storage room as kids and 300+ staff, I prefer a lean and fast approach to my fleet management today, i.e. mostly barques and the occasional frigate. That means to dump a lot of goods because you are out of storage really quickly but is the better approach in the long run.
Also nowadays I try to avoid fencing like hell since you can get wounded and that costs years of your prospective career.
Still, pick 'skill of fencing' as a beginner obviously.
Working on a 5 min multiplayer dungeon https://escapethe.app which the kids say “is actually fun”.
And taking a second crack at a feature flags with https://quonfig.com because I seem to be unable to put this problem down and finally feel like I have the right git native and agent first approach.
Someone told me that you have to have more expensive plans for people to have the confidence to try your cheap plans, which is sort of upside down at first glance and then you think, oh no, I'm like that. It's true.
I used GSD for a bit. It was helpful for a side project where I constantly forgot where I was in implementation. Helpful to be able to just say "Do the next thing"
I would imagine that for a non-engineer trying to code it would be quite useful / deliver a better result / less liable to end up in total mess. But for experienced engineers it quickly felt like overkill / claude itself just gets better and better. Particularly once we got agent swarms I left GSD and don't think I'll be back. But I would recommend it to non coders trying to code.
the duration one in particular bugs me. I work on a dynamic configuration system and i was super happy when we added proper duration support. we took the approach of storing in iso duration format as a string. so myconfig = `5s` then you get a duration object and can call myconfig.in_millis. so much better imo.
There are multiple distinct benefits to be had from feature flagging. Because it's the "normal" path, most FF products bundle them all together, but it's useful to split them out.
- The code / libraries for evaluating rules.
- The UI for creating rules, targeting & roll outs.
- The infrastructure for hosting the flags and providing real-time updates.
- Evaluation tracking / debugging to help you verify what's happening.
If you don't need #1 and #2 there, you might decide to DIY and build it yourself, but I think you shouldn't have to. Most feature flag tools today are usable in an offline mode. For Prefab it is: https://docs.prefab.cloud/docs/how-tos/offline-mode You can just do a CLI command to download the flags. Then boot the client off a downloaded file. With our pricing model that's totally free because we're really hardly doing anything for you. Most people use this functionality for CI environments, but I think it's a reasonable way to go for some orgs. It has 100% reliability and that's tough to beat.
You can do that if you DIY too, but there's so many nice to haves in actually having a tool / UI that has put some effort into it that I would encourage people not to go down that route.
entitlements is a huge one. Sooooo many orgs are in an absolute rats nest of confusion because half their entitlements are in something like an auth system, half are in something like billing and the third half is hacked into feature flags.
One particular pain point is that finance or something "do users with access to feature X retain better and it's super hard to figure out.
My overall feel is that developers are trying to solve a problem and that it turns out the configuration is as fundamentally as important as the software itself. I define "dynamic configuration" as "a key value store which takes context and has rules based system to give you a value". This primitive turns out to be extraordinarily useful and powerful. Rather than try to split it into N different systems, each custom / don't have telemetry / aren't available to all services SDKs. What if you have ONE BIG CONFIG system that really does a bang up job.
(Note: copying the big boys is not always the right move, but https://research.facebook.com/publications/holistic-configur... does give some credence that this is a decent approach)
By focussing on one terrific system, you can put all your eggs into the basket of making that reliable / comprehensible / flexible / strict.
The one on your list that I think DOESN'T belong would be permission checks at user level. The N of that is not a good fit for config (though when you look at the facebook paper, it's pretty wild how they've scaled it (but it doesn't do permissions afaik)).