Akka; Passing around too many parameters with EventSourcedBehavior - scala

Question

We are building a event sourced system based on Akka-Typed. We quickly fall in a situation where our states requires many parameters passed as implicits parameters.
There is a solution on the style guide to use an enclosing class; https://doc.akka.io/docs/akka/current/typed/style-guide.html#passing-around-too-many-parameters.
However this is for "simple" behaviors, not for EventSourcedBehaviors. This technique of using a enclosing class that produce behaviors does not work for event sourced one because an event sourced behavior is made of one command handler and one event handler.
In our case we have a State trait that define one method to received commands and another to handle events. If we apply the enclosing class technique we have to create anonymous classes for all states, but those cannot be serialized.
object SampleEventSourced {
trait State extends CborSerializable {
def execute(cmd: Command): ReplyEffect
def apply(evt: Event): State
}
def apply(
persistenceId: PersistenceId,
config: Config,
): Behavior[Command] = {
EventSourcedBehavior
.withEnforcedReplies[Command, Event, State](
persistenceId,
new SampleEventSourced(config).empty(),
(state, cmd) => state.execute(cmd),
(state, evt) => state.apply(evt)
)// ...
}
}
class SampleEventSourced private(config: Config) {
import SampleEventSourced._
private def empty(): State = new State {
override def execute(cmd: Command): ReplyEffect = cmd match {
// ..
}
override def apply(evt: Event): State = evt match {
// ..
}
}
java.lang.IllegalArgumentException: Empty State [org.acme.SampleEventSourced$$anon$1#36d7d2fe] isn't serializable.
One solution would be to duplicate the creation of the event sourced behavior in each "state" method. But that will produce a lot of duplication.
object SampleEventSourced {
def apply(
persistenceId: PersistenceId,
config: Config,
): Behavior[Command] = new SampleEventSourced(config).empty()
}
class SampleEventSourced private(config: Config) {
import SampleEventSourced._
private def empty(): Behavior[Command] = EventSourcedBehavior
.withEnforcedReplies[Command, Event, State](
persistenceId,
new State(),
(state, cmd) => state.execute(cmd),
(state, evt) => state.apply(evt)
)// ...
}
Another would be to create concrete subclasses of State but we will have to pass the parameters across all of those states.
object SampleEventSourced {
class EmptyState extends State(config:Config, otherUselessParameter:Any) {
// ...
override def apply(evt: Event): evt match {
case _ => new OtherState(config, otherUselessParameter)
}
}
class OtherState extends State(config:Config, veryImportantParameter:Any) {
// ..
}
}
Putting those state classes inside the enclosing class won't work because those non-static inner classes cannot be de-serialized.
So, what's your solution for this case, how do you deal with EventSourcedBehavior with states that require many parameters ?

Answer 1

The problem is that that jackson-cbor, on top of being reflection based, isn't that effective at serializing things done in an idiomatic Scala way (the only real point in its favor is that it's better than Java serialization).
So the immediately apparent solution is to:
model the state as an Algebraic Data Type (generally a sealed trait extended by case classes and maybe a case object for the empty/initial state case).
don't serialize them via Jackson, but use a native-to-Scala serializer (e.g. play-json, circe, etc.) and an Akka serializer leveraging that serializer; it's likely easier to define a marker trait (e.g. CirceSerializable) so that in the configuration you only have to worry about one binding. Events & state will want to be marked with that trait: commands and their replies (at least the ones that could be sent over the network might also as well).
One subtlety to be aware of when defining your serializer is that, the native-to-Scala serializers will generally use some form of typeclass derivation at compile time, but this will be complicated if there's a need to serialize ActorRef, as a serializer for ActorRef is best done with the aid of the ActorSystem (EntityRef can now be inspected for serialization, and conceptually makes more sense for persistence, given the lifecycle, but that's going to be fairly custom): you'll therefore probably want to delay derivation of the ActorRef serializer/deserializer until the ActorSystem starts up and also delay derivation of the events/state/commands/replies containing ActorRefs until after then.
I'd probably tend to make the handler for each event a method in the sealed trait without letting the state have any knowledge of how events are reified. The benefit of this is that you can unit test the state transitions without needing events or commands.
case class ItemAdded(name: String) extends Event
sealed trait State {
def items: Set[String]
def addItem(name: String): State.NonEmpty
}
object State {
case object Empty extends State {
def items: Set[String] = Set.empty
def addItem(name: String): NonEmpty = NonEmpty(Set(name))
}
case class NonEmpty(items: Set[String]) extends State {
def addItem(name: String): NonEmpty = copy(items = items + name)
}
}
Then your event handler is pretty thin
(state, evt) => {
evt match {
case ItemAdded(name) => state.addItem(name)
}
}
Depending on how much validation your command handlers take on, those can get complex. The operative principle is that commands are interpreted into zero-or-more events, and events are interpreted into operations (methods on state which result in a new state) on the state. The state should thus have sufficient query methods (e.g. items) to allow the command-handler to consume a state.