Welcome to the last part of dice game post series!
Today we’ll see how we can take advantage of the fact that we’re using event sourcing.
We’ll create a separate statistics project that will catch all
DiceRolled events and count how many times each number have been rolled.
For the statistics storage we’ll once again use Akka persistence. In fact it’s such a simple case that any storage mechanism will work great, anyway we’re already revolving around event sourcing so why not use it one more time. Of course the events saved inside statistics module are completely separate from the game’s ones, thus the term event may refer to either game event or statistics eventdepending on the context it’s used in.
We’ll also create a REST API to access the statistical data. A single GET route will suffice here.
Summing up, here’s what we’ll need to do:
- catch events
- update and store the statistics
- expose REST API
I’ll focus on each of these in the corresponding sections below.
Similar to the webapp part, here, once again, we’ll use Reactive Rabbit to consume the events from RabbitMQ.
We’ll create another queue and bind it to the events exchange:
"x-match" -> "all", "type" -> "DiceRolled" bind arguments mean: “I want to receive
DiceRolled events from all played games”.
Once the queue is created and bound all incoming events are routed to
SubscriberActor (which is given a reference to
statsActor – more on which later):
It extracts the
rolledNumber value from each incoming event and notifies
statsActor that it should increment the rolls count for the given number.
Notice that for this use case we don’t need to map incoming event to any case class. We’re only interested in one field:
rolledNumber and that’s what we extract.
Now it’s time to take a look at the
PersistentActor that can handle
IncRollsCount command. Once it receives it,
RollsCountIncreased event is generated and saved.
If you’d like to read more about
PersistentActor, please refer to the 1st partof this series.
The internal state is just a simple case class that stores all needed information (a Map of “rolled number” -> “total rolls count” entries).
Another message that
StatsActor handles is
GetState that sends back the current state to the sender.
Finally, we need a way to access our data from outside.
Let’s setup a simple spray server for it. It’ll handle the
We follow the actor-per-request pattern here, that means for every stats request we create a
GetStatsRequestActor actor to handle it:
It fires the
GetState query to
statsActor and waits for the response. Once the response arrives it completes the request with formatted data:
Now that we have all needed components, it’s time to test our statistics service.
First, let’s run everything we need, i.e.:
- game backend server
- game frontend app
- our shiny statistics app
Here are the commands I use:
If everything went good, we should now have all services running.
What does our statistics service return? Let’s check that…
As expected, we don’t have any dice rolls statistics yet. It should change after playing some rounds. Here’s what I got a few rounds later:
Great! We now have the information how many times each of the numbers have been rolled.
Good news, we’ve gone through the final part of this series. We have a working backend, frontend, and now, also a separate statistics service.
As you can see, it’s not that difficult to use CQRS/ES in a project. On the contrary, it can make some things easier. It obviously doesn’t fit all use cases, but it works especially well when there are lots of asynchronous stuff going on.
As you can see in the example of
StatsActor, Akka persistence is not reserved for big, complex projects – it can, as well, easily be used in smaller ones. Whether you find it useful or not, I hope you enjoyed reading and will come back to us for more!
Don’t hasitate to clone the repo and play with it a little. Just to remind, full source code is available on GitHub.
Below, you’ll find a list of various resources I came across that I find readworthy.
Thanks for reading!
- Event-sourced game implementation example – Part 1/3: Getting started
- Event-sourced game implementation example – Part 2/3: It’s time to play – building web application