Event-sourced game implementation example – Part 2/3: Building web application

Welcome to the 2nd part of the event-sourced game post series! In case you haven’t yet read the previous part, I highly recommend reading it before.

Today we’ll focus on the frontend server part, the one that’ll be responsible for handling user interface interactions as well as backend server communication.

What do we have so far?

Quick recap of what has been done so far in part 1:

  • we’ve implemented a backend server that lets us play games using its REST API
  • we’ve been able to peek at generated game events in the RabbitMQ console

Now it’s time to create a UI that’ll seamlessly combine the two to create a decent user experience. Here’s what it will look like:

demo-gif

For this, we’ll use:

  • Play! Framework as our frontend server
  • WebSocket for real-time browser <-> frontend server communication
  • Reactive rabbit to receive game events from RabbitMQ
  • AngularJS on the UI side

The action flow from the UI point of view will be as follows:

  • the user creates a new game (the command is sent)
  • the game is created (the response is received)
  • UI binds itself to events from a newly created game (WebSocket connection is created)
  • the user chooses the players count and starts the game (the command is sent)
  • GameStarted event is received through WebSocket connection, the UI is updated
  • the user chooses the player and rolls the dice (the command is sent)
  • DiceRolled events are received, the UI is updated

Looking at these, our Play! the server will need to handle:

  • routes to execute commands
  • WebSocket route to receive events from a given game

Controllers

First, let’s add these routes to our Play! application:

[conf/routes]

POST ones are for commands and the GET route is for websocket connection. Let’s take a look at the implementation.

Commands routes:

[MainController.scala]

Nothing special here, commands are just forwarded to our backend server (with some additional responses mapping).

Websocket route is a little bit more complex:

[MainController.scala]

acceptWithActor takes two type parameters: one for incoming messages (it’s just a String, since we don’t send anything to the server anyway) and another for outgoing messages, which are GameEvents.

[GameEvent.scala]

To make it work that way we need to tell Play! how to actually send GameEvent through WebSocket. It’s done by bringing implicit FrameFormatter[GameEvent] to the scope. We’ll format GameEvents as JSON and use FrameFormatter.jsonFrame which Play! provides:

[MainController.scala]

What’s next in acceptWithActor is a method that takes a HTTP request and an ActorRef out (which is used to send messages from server to client) and returns Props to create WebSocket connection handling Actor. We’re telling it to create one WebsocketEventPublisher for every WebSocket connection, we also pass out reference to it, which it can later use to send messages through the connection.

Receiving and passing events

Let’s have a closer look at WebsocketEventPublisher.

[WebsocketEventPublisher.scala]

What we do, when the actor starts, is create a new queue and bind it to the events from given game. It’s the last parameter in queueBind – argumentswhich says “hey, I want to receive only events from the game with id == gameId”.

Once the queue is bound, we create a Source out of it, which we attach Sinkto. Our sink is an EventSubscriber actor, which will receive every incoming event (or, at this point, rather a message that represents an event).

[EventSubscriber.scala]

Once it receives an event, it’ll pass it back to WebsocketEventPublisher(that’s why we pass self reference to its props).WebsocketEventPublisher will pass it further, to out reference (which will use FrameFormatter to serialize the message and send it through WebSocket connection).

[WebsocketEventPublisher.scala]

requestStrategy in EventSubscriber tells streams implementations how many more messages the actor wants to receive.

Here it’s implemented to always be at least 1, meaning we want to receive as many messages as there are. It may not however be always appropriate elsewhere. I don’t want to focus too much on back pressure in this post, so we’ll just stick with this.

Those watchful may say that it doesn’t look good to pass these rather backend-side events directly to the browser. It’s true, usually, some additional processing/validation would be added before passing them to WebSocket, but it’s not necessary for our simple application.

Frontend part

Now that we have our backend stuff ready, let’s see how can we use it on the frontend.

Services

Let’s start with two Angular services:

  • one for sending commands (create game, start game, roll the dice)
  • and another for subscribing to events for a given game (using our WebSocket endpoint)

Here’s what they both look like:

[services]

There’s really nothing special here, I won’t even comment the command part – these are just http POSTs.

On the event side, we simply broadcast every incoming message, were the name parameter of $broadcast contains an event type so that we can later easily listen for a particular game event.

Controllers

User at given time can see one of three pages (stored in rootScope):

[app.js]

This variable determines the currently shown content (and used controller) with ng-switch:

[index.scala.html]

Each controller handles a different set of user actions, let’s examine them:

The first one is CreateGameController:

[create_game_controller.js]

It’s really simple. It just POSTs to create a new game and upon success connects the event service to the event stream, changing the currently shown page to choose_players with corresponding StartGameController:

[start_game_controller.js]

This gives the user the possibility to specify players’ count and handles the “Start game” button click. It also shows a popover in case of an error.

If there were no errors and the game was started, GameStarted event is handled in the main application:

[app.js]

The game state is stored in the game variable in rootScope and is updated according to the events received:

[app.js]

Finally, we have GameController that handles user inputs when the game is running:

[game_controller.js]

It also listens to game events to update the view accordingly. When the game is finished the “Play Again” button is visible which, upon clicking, redirects the user back to the “create” view.

You can find all the related views in index.scala.html file.

Summary

That’s it for the 2nd part. Our game is ready :)

We can now consume events from RabbitMQ and send commands to our backend server. Both functionalities are seamlessly integrated into our modest interface and the distinction is invisible to the user. But the fun is not over yet. In the 3rd part, we’ll see how easy it is to grab some statistics from the games played and expose collected data.

As usual, the full source code is available on GitHub.

Other parts:

Links

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

See also

Authors

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

Łukasz Gąsior
Łukasz Gajowy

I’m a (currently Scala) Software Developer, Apache Committer (Beam), and a good software design enthusiast. I like statically-typed functional programming, working with cutting-edge technologies and doing technical research for new projects. You can follow me on Twitter (@lgajowy)!

Latest Blogposts

24.11.2023 / By  Sylwia Wysocka

Navigating the Future at Web Summit 2023: A First-Timer’s Reflection

Insights and Reflections: My First Web Summit Experience Join me, a business development specialist from Scalac, on my first-ever journey through the buzzing halls of Web Summit 2023 in Lisbon. As I stepped into this ocean of innovation and opportunity, I was filled with a mix of excitement and curiosity. What unfolded over the next […]

22.11.2023 / By  Michał Talaśka

Scalac’s Black Week: Exclusive Offers!

Scala, Java, Go and Rust experts for your project. This Black Week, Scalac is excited to offer some incredible deals that are just too good to pass up. Whether you’re looking to optimize your existing project or start a new one, we’ve got you covered with our special promotions. Check them out: 50% Discount on […]

07.11.2023 / By  Michał Szulczewski

AI for programmers

Introduction – towards the using AI in software develompent With the growing discussions about the integration of artificial intelligence (AI) into software development via tools like ChatGPT and Github Copilot, I have explored these AI-driven coding aids for some time. Initially, I engaged with Tabnine, a tool similar in function to Github Copilot, albeit a […]

Need a successful project?

Estimate project