Comment by ivarconr
1 day ago
Hi HN, I'm Ivar, creator of Unleash.
Unleash started in 2014 as an internal tool at my company at the time, because we wanted to ship to production continuously without big-bang releases. It's an Open-Source feature flag platform with SDKs for >25 languages.
A few design choices that might be interesting:
- Local evaluation: server-side SDKs fetch the flag config and evaluate in-process, so user data never leaves your app and a flag check is a memory lookup, not a network call.
- Shared Rust engine (Yggdrasil): the evaluation logic is written once in Rust and embedded in the SDKs, so behaviour is the same across languages.
- Unleash Edge: a Rust proxy/cache for frontend and edge clients at scale. (Commercial)
- OpenFeature: supported if you don't want to lock into our SDKs.
We were happy customers with my startup (before we died).
Unleash does a lot more than it seems on first look. It helped us a ton as we were shooting in all directions searching for pmf.
The local evaluation part is interesting. How do you keep the client’s evaluation engine up to date with the product features?
That's a great question, and the honest answer is that it is hard. We can easily add new capabilities in the UI, but for the Unleash protocol itself we need to make sure all changes are backward compatible, because we do not control the SDK version.
We have a few tricks we apply:
- Yggdrasil is the "Unleash SDK Engine". Written in rust and cross-compiled to multiple languages. This makes it easier to add features, and ensures all SDKs implements the protocol the same way. https://github.com/Unleash/yggdrasil
- Try to have a simple and generic protocol - This allows us to add new targeting capabilities later, without having to change the SDKs. In practice I must admit this is not easy and have only been possible in a few scenarios
- Make sure the SDK report their protocol version. This allows you do adapt the product to tell the user to upgrade to get new features. We also leveraged the SDK version when we introduced segments, as we could rewrite those to a less performant format in the API, to simplify the rollout.
I can see using something mature if you are starting from scratch.
if you already are in a platform capture situation, eg. Azure App Configuration or AWS AppConfig where you already integrate with platform tools using the native auth primitives, what is the benefit one can expect from switching to unleash?
If your current platform support (AppConfig etc) is sufficient, you should probably keep using it.
We see teams move when they have more complicated needs, either in terms of compliance, 4-eyes approvals, scalability and lifecycle tracking.
Anything you’re missing today, or is it working fine?
[flagged]