feat: yggdrasil engine

[sighphyre]

What's this?

This swaps out the logic for feature toggles in the SDK by using Yggdrasil. In particular, constructs that are now removed are:

• Evaluation logic for feature flags (this means strategies, constraints, enabled)
• Metrics calculations, but sending metrics are still handled by the SDK itself
• Custom strategies, with a bunch of glue code

For consideration

• Perhaps controversial but I've also trimmed back the logic for custom strategies, a lot of this was to support the legacy way of registering custom strategies and has been marked as deprecated for some time. Yggdrasil won't let the caller get hooks into the custom strategies and so a lot of this isn't really possible anymore

• We have no JRuby implementation right now, that's possible with Yggdrassil but not trivial. JRuby seems fairly important so we need to make a plan for this

• Release strategy for this. It's a big change and we should be careful here

[rarruda]

This is awesome work!

But as early feedback, these are my initial thoughts:

should we consider having:

1. one Gem, which a configurable engine parameter, where one could toggle between the pure ruby implementation and the rust implementation? (or eventually additionally for JRuby java/jar/jni-ruby implementations).
2. one Gem, where the implementation of the client would get dynamically detected and loaded. The gem for murmur hash we use is a good example of how it can be done for automatic loading, where the base functionality can be provided from C, Java or PureRuby w/o any configuration.
3. two separate Gems, one with the pure Ruby implementation and one with the rust implementation. Both could co-exist in one repo, to help keep the public method signatures in sync.

I think the current implementation should co-exist until there is full feature parity and we have enough testing done with the client using rust implementation of the engine.

There is also a question on how we would provide custom strategies, etc, but I think that is less relevant to bring up at the moment.

Otherwise, I only have kudos to give! This is really awesome and impressive!

[sighphyre]

So this:

I think the current implementation should co-exist until there is full feature parity and we have enough testing done with the client using rust implementation of the engine.

Is an excellent idea and I'd like to do that. Yggdrasil is surprisingly more battle tested than it appears, since it forms the core of Edge and Edge has been feature complete for 6 months or so (minus custom strategies). The Ruby engine from Yggdrasil is a pretty thin wrapper around that but there's always scope for things to go wrong with such a large change.

Medium to long term, the Ruby implementation won't be able to keep up with Yggdrasil unless it implements a full grammar parser (which I don't think is sane) so the pure Ruby implementation days are probably coming to an end in the next few months to years. I'm not convinced about pulling the existing Ruby engine in the SDK code out into a separate gem because of that (and I also don't want to deal with potential issues with refactoring that out on top of this complexity). I had kinda of thought to revert all the deletes and toggle between Yggdrasil and the existing code within the SDK. Once we're happy it works we can cull out the existing implementation. Idle thoughts still

Custom strategies are coming! I have a blob of terribly ugly code on my machine that is a drop in replacement for custom strategies here but it needs work before more eyes see it.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sighphyre]

Shhh stalebot, shh.

[sighphyre]

Bootstrap only should be a viable option (we can do this in the others), relaxing this constraint makes testing a ton easier but I may be able to roll this one back if we need

[rarruda]

Valid point.

[sighphyre]

For Yggdrasil to use so we can send the context as a JSON blob

[coveralls]

Pull Request Test Coverage Report for Build 8002626095

Details

• 0 of 66 (100.0%) changed or added relevant lines in 8 files are covered.
• 4 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-1.6%) to 95.532%

---

Files with Coverage Reduction	New Missed Lines	%
lib/unleash/client.rb	2	87.5%
lib/unleash/toggle_fetcher.rb	2	93.22%

Totals
Change from base Build 7444190517:	-1.6%
Covered Lines:	449
Relevant Lines:	470

---

💛 - Coveralls

[sighphyre]

@rarruda Okay, this is coming out of draft. We've spoke a lot internally about keeping a pure Ruby impl around but I think we'd rather go forward and if folks need a pure Ruby impl they can use a previous version until they can upgrade.

Coverage is failing but looking at the details, a lot of that is because of the massive LOC reduction on this. There's little but logging that isn't covered.

[daveleek]

Why is this optional here? It doesn't seem optional in client.rb

[sighphyre]

Good question! This may be my Rust opinions coming through here. The Client is owns the engine and makes it available to everything else when it's started up. Everything else may or may not have access to it, so this is paranoia and memory and ownership hygiene

[chriswk]

This looks reasonable to me. Can't wait to see Yggdrasil take over the rest of our SDKs as well :)

[daveleek]

Awesome!

[rarruda]

After looking extremely superficially at the PR:

• code coverage is not so important as an absolute metric with such a refactor. Totally ok to just ignore it in this case.
• As you support jruby natively through yggdrasil, i think it is then a good idea to drop the pluggable engine concept.
• i would recommend merging bb2d922 in a last release of the current major branch, so you can more easily collect usage statistics of the current and next major releases from the unleash cloud.
• i would consider creating a beta release/pre-release gem before the major release of the new refactored gem, and collect feedback if possible from early adopters, before rolling out a major release. You never know what production will bring.
• i would suggest also adding to the README.md, info with regards on how to migrate to the new configuration format (assuming it has changed), updating the sample code in examples/ and updating the CHANGELOG.md.

all of the above can be done in a separate branch, before merging to master, but it is not strictly required.

an extra thought then is that it might also be a good idea to have a pointer in the README in the master branch a pointer to the pre release branch, so to make it more obvious what the roadmap is.

This is amazing work! ❤️

I hope someone bakes you a cake 🍰 and buys you a beer 🍺 !