Orleans

LimeLeague is built on top of a dotnet core framework Orleans.

Why?⌗

One, I wanted to try something new. Two, I wanted to be able to use Google DataStore in a safe manner without any manual locking. I had been flirting with various actor frameworks for a few years. Orleans, proto.actor and Akka.net, each one came with it’s pros and cons and I gave each of them a whirl. I originally chose proto.actor but has I started using it for real some limitations starting to crop up that Orleans solved so I switch to that.

Welcome to Pain⌗

Orleans is a pain to use. The documentation hasn’t kept up with the releases. Some things aren’t documented at all. Sometimes providers behave in weird ways you don’t expect. Debugging in a black art, since it is a distributed system your grains can easily cross boundaries. It is NOT a general purpose solution and trying to build one is folly with it. It is a new paradigm for people to learn and is often clunky to get up to speed. The actual start time is painful when in the compile build loop. I have not found a good way to quickly or easily scale down a cluster.

Why the hell am I still using it?⌗

It allows me to think of things has discrete units without worrying about cache, overlap or multi threading. A grain can be a unit of work, cache and orchestrator all in one thread safe package. The ability to keep state in memory and ensure all requests go though that means it acts has my cache and my webpage times can be blazing fast. (Note I still use Redis for some caching) It’s distributed, one machine goes down and it handles the jitter. It’s fun! It’s well thought out. It has current and reasonable releases. Did I mention it’s fun?

The future?⌗

Ask me in a year if it was a good idea.