3 Reasons Why Akka Typed Helps You Write Better Code
This article is for programmers who know the main idea of Akka — actors as an alternative to writing scalable distributed systems. I'll also make some comparisons with the old "classic" API, but knowing it is not necessary.
You can also find this post over at the Rock the JVM blog and in video form on YouTube or attached below:
Akka Typed is widely praised for bringing compile-time checks to actors and a whole new actor API. The problem is that even this new typed API has loopholes that almost never completely close the old Akka anti-patterns. However, the 2.6 API is a big step in the right direction, because although the API is not airtight, it's extremely powerful in the way that it shapes incentives to write good code. Let me give some examples of some of the most basic things.
Typed Messages
Let me start with the obvious: the messages an actor can receive will be reflected in the type of the actor, and vice-versa: the type of its ActorRef will be both a reason for the compiler to yell at you if you don't send a message of the right type, and also an indication to the user of the actor about what it's supposed to do. Let me give an example:
Scala
xxxxxxxxxx
1
20
1
trait ShoppingCartMessage
2
case class AddItem(item: String) extends ShoppingCartMessage
3
case class RemoveItem(item: String) extends ShoppingCartMessage
4
case object ValidateCart extends ShoppingCartMessage
5
6
val shoppingActor = ActorSystem(
7
Behaviors.receiveMessage[ShoppingCartMessage] { message =>
8
message match {
9
case AddItem(item) =>
10
println(s"adding $item")
11
case RemoveItem(item) =>
12
println(s"removing $item")
13
case ValidateCart =>
14
println("checking cart")
15
}
16
17
Behaviors.same
18
},
19
"simpleShoppingActor"
20
)
Please ignore that I'm catastrophically using Double for currency, and don't try this at home (or in production). The problem with the new typed behaviors is that messages are still pattern-matched, and it's very unlikely that in your big-ass application an actor will process a single message type EVER. However, the natural tendency is to think of an actor as receiving a message from a given hierarchy, which leads to a nice OO-type structure of messages. Of course, you can circumvent this and use Any, but why would you do that? Right from the moment of typing Any there you probably get an icy feel in the back of your neck that there's something wrong with your code.
Additionally, if your message hierarchy is sealed, then the compiler will also help you treat every case.
Mutable State
Mutable state was discouraged in Akka from the very beginning. If you remember the old "classic" API, we had this context-become pattern to change actor behavior and hold immutable "state" in method arguments returning receive handlers. Variables and mutable state have not disappeared:
Scala
xxxxxxxxxx
1
21
1
val shoppingActorMutable = ActorSystem(
2
Behaviors.setup { _ =>
3
var items: Set[String] = Set()
4
5
Behaviors.receiveMessage[ShoppingCartMessage] {
6
case AddItem(item) =>
7
println(s"adding $item")
8
items = items + item
9
Behaviors.same
10
case RemoveItem(item) =>
11
println(s"depositing $item")
12
items = items — item
13
Behaviors.same
14
case ValidateCart =>
15
println(s"checking cart: $items")
16
Behaviors.same
17
// can also try with pattern matching and returning Behavior.same once
18
}
19
},
20
"mutableShoppingActor"
21
)
However, in most Behavior factories — if not all, I'm not 100% up to speed yet — you are forced to return a new behavior after a message is being handled. In other words, the behavior changing is baked into the API now. With this in mind, it's much easier to create different behaviors and have the actors adapt in a more logical way:
Scala
xxxxxxxxxx
1
12
1
def shoppingBehavior(items: Set[String]): Behavior[ShoppingCartMessage] =
2
Behaviors.receiveMessage[ShoppingCartMessage] {
3
case AddItem(item) =>
4
println(s"adding $item")
5
shoppingBehavior(items + item)
6
case RemoveItem(item) =>
7
println(s"removing $item")
8
shoppingBehavior(items — item)
9
case ValidateCart =>
10
println(s"checking cart: $items")
11
Behaviors.same
12
}
So why would you need variables anymore when you have this logical code structure that avoids mutable state altogether? Much easier to write good code.
Actor Hierarchy
One of the massive benefits of Akka was the "let it crash" mentality embedded into the toolkit. This was achieved by making the actors maintain a supervision hierarchy, in which if an actor fails, then its parent — which acts like a supervisor — can deal with the failure and decide whether to restart the actor, stop it, resume it or simply escalate to its parent.
A common anti-pattern of the old Akka API was spawning very flat hierarchies, which destroyed this massive benefit. The crux of the problem was the easily usable system.actorOf. Everyone anywhere could go "system.actorOf" left and right and all of a sudden you had massive groups of actors managed by the same user guardian actor with the default supervision strategy.
In the new API, we don't have that. No more system.actorOf. You are now forced to think of the actor hierarchy and how the root guardian will manage them. That's simply by the fact that you can't spawn actors AT ALL — you can only spawn child actors:
Scala
xxxxxxxxxx
1
1
val rootActor = ActorSystem(
2
Behaviors.setup[ShoppingCartMessage] { ctx =>
3
// create children
4
ctx.spawn(shoppingBehavior(Set()), "danielsShoppingCart")
5
// no behavior in the root actor directly
6
Behaviors.empty
7
},
8
"onlineStore"
9
)
So even if your root actor doesn't handle messages itself, the fact that you can only spawn actors from a hierarchy is a huge win. It forces you to be a good citizen and embed actor hierarchy — and thus supervision — into your code.
A Way Forward
This new API redefines what "normal" code should look like, and for the most part, it's shepherding Akka code in the right direction. As I mentioned earlier, the API is not airtight and it can still be circumvented, but expect to see better Akka code in the future simply by the tools we now have at our disposal.
