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:

[StatsApp.scala]

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):

[SubscriberActor.scala]

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.

[StatsActor.scala]

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).

[Stats.scala]

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:

[StatsApi.scala]

We follow the actor-per-request pattern here, that means for every stats request we create a GetStatsRequestActor actor to handle it:

[GetStatsRequestActor.scala]

It fires the GetState query to statsActor and waits for the response. Once the response arrives it completes the request with formatted data:

[StatsApi.scala]

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

• Event-sourced game implementation example – Part 1/3: Getting started
• Event-sourced game implementation example – Part 2/3: Building web application
• Rest Assured API Testing Tutorial. How To Use Rest Assured With Java And Scala.
• The Top Scalac’s Posts of 2020
• Using Akka HTTP with Sangria as GraphQL backend