Event-sourced game implementation example – Part 3/3: Grabbing some data – statistics service
Welcome to the last part of dice game post series!
We already have fully working game that we created in 1st and 2nd parts.
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.
Catching events
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:
The "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.
Storing events
Now it’s time to take a look at the StatsActor
itself.
It’s a PersistentActor
that can handle IncRollsCount
command. Once it receives it, RollsCountIncreased
event is generated and saved.
Here, in contrast to GameActor
(link) from 1st part, persistenceId
is constant as we’ll have only one instance of StatsActor
ever (created when the application starts).
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.
REST API
Finally, we need a way to access our data from outside.
Let’s setup a simple spray server for it. It’ll handle the stats
route:
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:
Testing
Now that we have all needed components, it’s time to test our statistics service.
First, let’s run everything we need, i.e.:
- RabbitMQ
- 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.
Summary
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!
Other parts:
- 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
Links
- https://github.com/ScalaConsultants/reactive-rabbit
- https://blog.zilverline.com/2011/02/01/towards-an-immutable-domain-model-introduction-part-1/
- https://martinfowler.com/eaaDev/EventSourcing.html
- https://www.slideshare.net/ktoso/akka-persistence-event-sourcing-in-30-minutes
- https://pkaczor.blogspot.com/2014/04/reactive-ddd-with-akka.html
- https://doc.akka.io/docs/akka/snapshot/scala/persistence.html
Do you like this post? Want to stay updated? Follow us on Twitter or subscribe to our Feed.
See also