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

Links

Do you like this post? Want to stay updated? Follow us on Twitter or subscribe to our Feed.

Author

Łukasz Gąsior

I'm a passionate Scala developer, working on commercial Java and Scala projects since 2013. I'm a big fan of DDD, CQRS/ES and distributed systems. I've been using technologies such as Akka (Core, Persistence, Streams, Cluster), Play! Framework, Spray and many others.

Latest Blogposts

20.01.2021 / By Daria Karasek

Why Developers Should Pay Attention to ZIO in 2021

We already know the cases of companies big, and small adopting ZIO in their production apps. So, how is this change coming? Let’s explore it in more detail.

20.01.2021 / By Mateusz Sokół

Build your own Kafka in ZIO – Queues & Fibers

Queuing and messaging platforms have been gaining in popularity in recent years. They solve numerous problems based on asynchronous message passing or consumer and producer patterns. In this blog post, we're going to build a basic message broker functionality with ZIO for our internal clinic messaging system, specifically with ZIO Queues and ZIO Fibers.

19.01.2021 / By Tomasz Bogus

Best Practices for Upskilling Your Software Development Team

Looking for upskilling examples to engage your software development team? Read our expert article on methods that work in the tech industry

Need a successful project?

Estimate project