Akka.NET community news

with 7 Comments

This is just a quick follow up on what is going on in the Akka.NET community.

On our last core developer meeting we discussed a few topics, do note that nothing here is set in stone, things may change in the future but here are the topics we have been discussing:

Paket for dependency management

We are aiming to remove the old Nuget based dependency management for the Akka.NET project and replace it with Paket instead.
This only relates to how the project is built and how we manage dependencies internally.
The reason for this is that we are seeing problems with versioning of core dependencies, some modules have references to different versions of the same 3rd party libraries, e.g. Json.NET, ProtoBuf etc.

Switching default Serializer

Our current serializer; Json.NET have served us well for the 1.5+ years Akka.NET have been developed, however, there have been quite a few problems making play nice with F# types.
The current plan is to switch default serializer to Wire, a binary serializer specifically developed for for Akka.NET.

We are also planning to change how the default serializer handles object graphs.
Currently, we allow almost every possible object graph to be serialized and passed as a message, the original intention here was to reduce as much friction as possible for developers to design their messages.
However, that turned out to lead to some anti-patterns, were large cyclic graphs are used as messages by some users.
This will still be possible by using the old serializer to preserve backwards compatibility.
The new serializer will however not allow cyclic graphs, messages are supposed to be used for pattern matching.

Switching default Transport

Now that Microsoft have ported Netty to .NET, we plan to replace the current Helios based transport with a DotNetty based one.
This will bring us features like TLS support and fix some of the current issues that relate to message order guarantees.

Cluster Sharding, Cluster Tools and Distributed Data modules

We are working hard to bring in these modules over to .NET.
There are now working examples of Cluster Singleton in the cluster-sharding branch of the main repository.

Bringing Akka.Cluster out of Beta

Akka.Cluster have been stable for a long time, there are however still some quirks with the MultiNode TestKit, we want to fix those before removing the beta label of the cluster module.

Stay tuned for more Akka.NET news.

Follow Roger Alsing:

Developer, Mentor and Architect. Co-Founder of the Akka.NET actor model framework. akka.nethouse.se

7 Responses

  1. Johan Classon
    | Reply

    Switching to DotNetty sounds exciting! TLS would be a really useful feature. And I see that Aaronontheweb is/was a contributor to Azure/DotNetty. Nice!
    I read about that java-netty support http and web sockets. Do you think that a javascript akka client would be possible in the future? (I have no idea how hard binary serialization is in javascript land, but one could use standard json serialization for this use case.)

    • Ed Blackburn
      | Reply

      I’ve wondered this a few times. But the idea of publishing sockets across the internet makes me think I should just build projections and use more conventional approaches for the website instead. Perhaps more useful for a node front end but then surely node / [dot]netty can’t be too difficult to interop?

    • Roger Alsing
      | Reply

      Regarding a JS client for Akka.NET, no I don’t see that as a possibility, Akka Remote is not intended for communication to non Akka Remote nodes. if you want to integrate web technologies to interact with your Akka actors, having a SignalR hub receiving messages and then piping them into an actor system is only a few lines of code.
      See http://getakka.net/docs/deployment-scenarios/ASP%20NET for an example on how to interop from e.g. Asp.NET.

  2. Eirik Tsarpalis
    | Reply

    I’d be interested to find out why you consider cyclic object graphs to be an anti-pattern. Not all cyclic objects are large, and conversely not all large objects are cyclic. I say this because in certain instances being able to serialize cyclic objects is genuinely useful. For instance, lambdas/closures can often be cyclic. When designing actor-based systems, I sometimes incorporate actors that accept lambdas as messages. Not being able to serialize cyclic objects would certainly hurt such functionality.

  3. Roger Alsing
    | Reply

    We just want to promote the idea of message as a value, we do support configurable serializers for any type, so if anyone needs to serialize graphs or delegates, they still have the option to do so.
    But to promote good message design, we do think that a stricter set of rules would benefit how users reason about messages.

    • Eirik Tsarpalis
      | Reply

      Ok, so I understand that you want to promote the principle that messages should be flat, which I agree is a good idea in most cases. However, trees/recursive types can be arbitrarily large, carry complex object graphs and still be acyclic. Why not also disable them while you’re at it?

  4. Kenneth Oksen
    | Reply

    Thank you for the update and great news regarding the cluster stuff!

    Keep up the good work to all..

Leave a Reply