Stateful Reactive Concurrent SPAs with SignalR and Akka.NET

Create reactive, near real-time, Single Page Applications (SPAs) that easily handle concurrency using the Actor Model and are not reliant on the database for the storage/retrieval of state. Multi-player online games are a great example, so that's what we'll build in this course.
Course info
Rating
(108)
Level
Intermediate
Updated
Nov 3, 2015
Duration
2h 34m
Table of contents
Description
Course info
Rating
(108)
Level
Intermediate
Updated
Nov 3, 2015
Duration
2h 34m
Description

The traditional stateless design for web apps can become increasingly troublesome with new classes of web apps and increasing end-user expectations. This traditional approach, where the web application is essentially a stateless front-end and all state is written/read to a database, falls short when we have ever-increasing workloads and requirements for highly responsive, near real-time systems. Add in the requirements for concurrency management, scalability and fault-tolerance, and the traditional approach becomes even less attractive. By combining the features of the Actor Model (Akka.NET) with the capabilities of SignalR and a front-end SPA library, we can more easily create next-generation reactive, stateful, and concurrent SPA web apps. In this course, we'll be using the example of multi-player online games, as these are a great example of reactive concurrency in action.

About the author
About the author

With over 15 years experience, Jason Roberts is a Microsoft .NET MVP, freelance developer, and author.

More from the author
Mocking with Moq and NUnit
Intermediate
1h 53m
Feb 22, 2019
Introduction to .NET Testing with NUnit 3
Intermediate
2h 6m
Dec 17, 2018
More courses by Jason Roberts
Section Introduction Transcripts
Section Introduction Transcripts

Building the Player and Game Controller Actors
Hi, welcome back. In the previous module we got an overview of the application that we're going to be building, and we got started in Visual Studio by creating our web application project and our class library project to hold our actors. In this module we're going to flesh out the class library project by adding some message classes and some actor classes. In this module we're going to start off by looking at the overall design of the different actors that we're going to be having in our actor system, so we'll look at the actors themselves and the kind of state that they hold, and also the messages that flow between these actors. We'll then jump into Visual Studio and start off by creating all of the message classes that we're going to need in our actors, and then we'll go ahead and create a player actor class, and we're going to have one instance of this actor class for every player that joins the game. Next, we'll create an actor that's going to help coordinate the action in the game, so this actor is going to be responsible for creating child player actors when players join the game, amongst other things. Finally, once we've created our actors, we're going to go and see how we can instantiate an Akka. NET actor system in ASP. NET. So we don't want to create a new actor system on each request that comes in. Instead, we want to maintain the single actor system that's going to be used for all requests, so we'll see how we can do this in ASP. NET.

Integrating Akka.NET with SignalR
Hi, welcome back. In the previous module we went and created our actors that are going to represent our players in the game and also the Game Controller Actor that's going to coordinate things for us. In this module, we're going to go and take these actors that we built in the previous module, and we're going to go and integrate them with SignalR. First off, we're going to get a brief high-level overview of what SignalR is if you haven't encountered it before, and then we'll jump into a diagram showing how all of the parts are going to fit together, so this is how our Actor Model is going to integrate with SignalR and ultimately our end client SPAs. Next we'll jump into Visual Studio and install and configure SignalR in our web application, and we'll also add some JavaScript SignalR functions to allow the server to call into our client SPA apps, so this is, for example, when player health changes. Next we're going to go and create an abstraction, this IGameEventsPusher, and we're going to use this abstraction to wire up an actor with SignalR. We're then going to go and create a SignalR Hub to allow us to create bidirectional communication between the client and server, and finally we'll go and create the actual SignalR Bridge Actor that's going to act as a conduit for messages flowing into and out of the rest of the actor system.

Completing the SPA Web User Interface with Knockout
Hi, welcome back to the penultimate module in this course. In the previous module we wired up SignalR with our Actor Model, and in this module we're going to go ahead and complete our SPA web user interface. We're going to be using KnockoutJS to do this, but similar techniques apply if you're using other frameworks, such as Angular. In this module, we're going to start off by getting a brief overview of KnockoutJS. KnockoutJS allows us to create a data-bound HTML user interface. It does this by creating the concept of a ViewModel in our JavaScript, which our HTML is bound to. We'll head into Visual Studio and create JavaScript ViewModels, one for players, and one for the overall game screen. We'll implement Knockout bindings in JavaScript functionality to allow a new player to join the game. When new players join the game, our Actor Model changes, and we use our SignalR Bridge to push these changes out to the client, so we'll go ahead and implement our Knockout data binding to react to new players that join, and we'll also go and implement the behavior that allows one player to attack another player. Finally, we'll see what happens if we're in the middle of the game and our ASP. NET application restarts. For example, this could be due to IIS restarting the app.

Hosting Game State in a Windows Service
Hi, welcome back to this final module. In this module we're going to see how we can overcome the problem of losing our game state when the ASP. NET application restarts. In this module, we're going to start off with a high-level overview of the concept of lightweight actor systems, and this is where we offload the main work of the application to some actors stored in a different process. In our example, we're going to see how we can store the game state in this process external to ASP. NET. To do this, we're going to start off with a simple console application, and this application is going to have an actor system, and inside this actor system is where we're going to store our player actors. Once we have this actor system running in this external process outside of ASP. NET, we'll go and modify our GameActorSystem class in our web application to point to this remote actor system in our console application rather than storing the player game state inside ASP. NET itself. We'll then fire up a browser, and we'll add a couple of players, and then restart our ASP. NET application, and we'll see that our game state is no longer destroyed, and that's because our game state will be held in this external console application process. While we can run our remote actor system inside a console application, it's usually better to go and create a Windows service. There's a number of benefits to this, including the fact that we don't have to be logged onto the server to host our game state, and we can use the Windows service infrastructure to manage the service.