With the recent Akka and Akka HTTP releases, there has never been a better time to start using Akka actors in your IT environment.  A highlight of the new Akka 2.6 release is the new typed Actor API officially becoming the main API for Akka.

For those who are already familiar with Akka, the new typed Akka API is recommended, but you are able to migrate at your own pace.  You even have the option of running typed and classic actors in the same actor system (i.e. ActorSystem).

In short, with typed actors, messages that are not a part of an actor’s defined message protocol cannot be sent to that actor.

Remember, to create a “classic” actor, you typically extend the Actor trait and override its receive method.  To create typed actors, this is no longer the case.  Now, you can define an apply method that returns a typed Behavior, which can be formulated using Akka Typed’s Behaviors DSL.

For example, the Behavior can be typed as a custom Command type, as shown below:

object SomeActor {

def apply(): Behavior[Command] = behavior( .. ) 

private def behavior( … ): Behavior[Command] = { … }
}

An example of such a Command can be a case class extending a Command sealed trait.  For example,

sealed trait Command

final case class CreateSomething(something: Something, replyTo: ActorRef[ActionPerformed]) extends Command

final case class ReadSomething( id: String, replyTo: ActorRef[ReadSomethingResponse]) extends Command

final case class UpdateSomething(id: String, replyTo: ActorRef[ActionPerformed]) extends Command

final case class DeleteSomething(id: String, replyTo: ActorRef[ActionPerformed]) extends Command 

Notice each one of these “commands” has an ActorRef. This is Akka Typed’s ActorRef.  Notice this ActorRef differs from the classic ActorRef in that this one is typed and the classic one is not.  In short, a message cannot be sent to a typed actor it cannot “understand.”

Reference:

https://akka.io/blog/news/2019/11/06/akka-2.6.0-released