Hyperlambda, a .Net Core based alternative to Windows Workflow Foundation

At this point in time, it’s painstakingly obvious that there’ll never be an official port of Windows Workflow Foundation to .Net Core. For those wondering why, read its name once more. “Windows” of course is the give away here, and .Net Core is all about portability. DotNet 5.0 is feature complete, and WWF is not on the list. Sure, there exists a community port of the project, but no official Microsoft release of WWF will ever reach .Net Core. Hence, a lot of companies are in need of an alternative as they move to .Net Core for obvious reasons.

If you study WWF, and what it actually does, it’s really just a dynamic rule based engine. Ignoring its visual aspects, and its drag and drop features, that’s all there is to it. Hence, whatever allows you to dynamically “route” between C# snippets of code, and dynamically orchestrates CLR code together, could arguably do its job.

The above description of “dynamically orchestrating CLR code”, just so happens to be exactly what Hyperlambda allows you to do. It’s a simple YAML’ish file format, with XPath capabilities, that doesn’t require recompilation or redeployment of your app in order to change its “rules”. This allows you to dynamically edit your “rules”, almost the same way you’d modify your configuration, or records in your database – Without even having to bring down your app, or even recompile anything in your assemblies.

For instance, one use case might be that you have some sort of Asterisk integration towards FreePBX or some other phone server. As you’re getting phone calls, you might imagine wanting to route these to different internal recipients, depending upon where the call originated from. For instance, a phone call originating from Australia, might be routed to your English speaking marketing department. While a phone call originating from Germany, you’d probably want to route to its German speaking equivalent.

This ruleset would be a tiny Hyperlambda file, with some 5-10 lines of code, and normally not something you’d want to hardcode into your C# code. By putting this into a Hyperlambda file, like some simple if/else or switch/case statement, you could later easily edit this file, if you for some reason decide to add another country to your back office. What would you do if you were opening up offices in China for instance? Recompile a C# assembly? I don’t think so. Still, this type of logic often over time tends to become too complex for a simple configuration setting. Hence you often need something that is 100% dynamic, yet Turing complete, allowing you to change it “on the fly”, without having to recompile and redeploy the app. You need a “dynamic scripting language for .Net Core” – Which actually perfectly describes Hyperlambda.

Advantages with Hyperlambda

Since Hyperlambda is not based upon reflection, it would probably perform at several orders of magnitudes faster than the equivalent Windows Workflow Foundation solution. I have worked with Workflow solutions, where a simple HTTP request into our Workflow engine, required sometimes 50 seconds to simply change a database record, Hyperlambda would easily cut that time in 10, possibly more. Jon Skeet measured reflection a couple of years ago in fact, and found it to be 200-400 times slower than typed delegates, and hence compiled lambda expressions, which the underlying Dependency Injection core of Hyperlambda is built upon. And in fact, my first implementation of Hyperlambda was built upon reflection, so my own experiences echos Skeet’s findings here. Add a single Dictionary lookup on top of a compiled lambda expression, and you basically have the execution speed of Hyperlambda “keywords”. This should easily be 50-100 times faster than Workflow Foundation – Although I can’t (yet) backup my claims with data here.

Disadvantages

Hyperlambda is not a programming language you’ll find books for at your local library. In fact, it’s probably the “smallest programming language in existence on the planet today”. This implies I’ll have to do some serious documentation for it, to allow for you to even start working with it. However, it’s not “new tech”, since I have been working with different permutations of it more less since 2013 myself, and tested it in a whole range of different environments. In addition, it’s arguably also simply a YAML’ish type of file format, combined with an XPath’ish type of expression engine, allowing you to rapidly feel at home if these technologies are something you know from before. Besides, I have done my best to make its tooling space rich, with a syntax highlighter and autocompleter implementation, based upon JavaScript in Magic’s frontend. But it would require some initial learning before you’re productive in it. Also, it has no visual “drag and drop” features, like WWF had – Which probably some people would count among its primary features for the record … 😉

Anyways, all in all, if you’re willing to learn something new, and you need a .Net Core based rule engine, I would definitely suggest you have a look at Hyperlambda. If you can’t wait till I document the thing, you can probably start out by looking at the unit tests for the “sub-modules” of Magic, and specifically their Unit Testing suite (298 unit tests++) – Which you can find at its main GitHub repository.

Download Magic and Hyperlambda from here if you want to play around with it …

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.