Proto Actor is a new lightweight actor library (and I say library, not framework) by one of the creators of Akka.NET.
Before going further, you might want to read up on why one should consider using the Actor model in the first place. Also, the Akka.NET docs are good for use cases too. If you’re really into it, the original Akka project for the JVM should be given a look as well.
Why use Proto Actor over Akka.NET or Microsoft Orleans?
Akka.NET was the first time I tried using the actor model in any real anger. Coming from a traditional enterprise software application development background (using, Dependency Injection, unit tests, etc.) I found several things off putting.
Props concept for creating actors felt wrong. Using DI wasn’t recommending. Testing actors required it’s own testing framework. Lastly, worst of all, using
await is an anti-pattern. Blasphemy!
I never got beyond a proof of concept with Akka.NET but it felt promising. It being a port of the original Akka with the HOCON config and all still didn’t sit right with me.
Next, I took a look at Orleans.
await is a first order thing. Virtual actors (or Grains) make lifetime management just a bit easier.
Downsides: the runtime silos still feel heavyweight and very closely tied to AppDomains. The generation of the serializable types is a bit clunky and very tied to the tooling provided. To be fair, they’re working on fixing much of what I didn’t like as their port to .NET Core requires much of it.
Again, I didn’t use Orleans much more than in a proof of concept. Primarily because of a project direction change. I almost deployed it to production.
Proto Actor is a library
Proto Actor does not use a runtime. In fact, it’s a set of fine grained libraries and relies mostly on 3rd party technologies to do a lot of the extra stuff (transport, serialization, logging, etc.) that aren’t the core of the actor concept.
Being cross-platform is first order concern for this project. While I don’t think I would recommend using Go and C# in the same cluster (though you could), the constraint means Proto Actor can only do things that are well known for both. Protobuf and gRPC for transport are good high performing well-known projects.
For the dotnet space, using
Microsoft.Extension namespaces for logging and configuration which are pluggable with the new ASP.NET Core libraries mean your favorite logging and config can be used.
So what now?
I’ve been using Proto Actor in a Winforms Application (I know!) to better model the threading and eventing not only from the user but from attached devices to the application. The interactions basically require queues (actor mailboxes) in order to process everything.
I’ve been using MediatR a lot recently to better organize the features of my cloud applications and this desktop application is no different. However, what is different is that things are much more stateful.
I have objects managing state and need a queue to read messages from. Guess what that is, an actor!
Each attached device is an actor. They have children which model the real world objects they’re tracking. HTTP connections are modeled as an actor with state. The UI forms are actors that accept messages to give user feedback and user actions are messages to other actors.
I think it works out nicely. I made a simple dispatcher to allow the Winform UI synchronization context to process messages. My UI code does not have to worry about calling
Up next: Proto Actors and DependencyInjection