Introduction to ASP.NET Core SignalR

 

What is ASP.NET Core SignalR?

    All internet-connected applications are composed of servers and clients. Clients rely on servers for data, and their primary mechanism for receiving data is through making Hypertext Transfer Protocol (HTTP) requests. Some client applications require data that changes frequently.

    ASP.NET Core SignalR provides an API for creating server-to-client remote procedure calls (RPCs). RPCs invoke functions on clients from the server-side .NET Core code. There are several supported platforms, each with its own client SDK. Because of this, the programming language being invoked by RPC calls varies.

    It's helpful to familiarize yourself with the common terminology that's associated with SignalR. In this unit, you'll learn what SignalR components are required in a server application versus those in client applications. Additionally, you'll gain an understanding of the various duplex communication mechanisms. SignalR encapsulates multiple real-time protocols and abstracts away the complexities of each implementation. For more information, see the ASP.NET Core SignalR documentation.

Transports

SignalR supports the following techniques, or transports, for handling real-time communication:

• WebSockets
• Server-Sent Events
• Long Polling

    The order in which the transports are listed here signifies their graceful fallback order. In other words, WebSockets is preferred over Server-Sent Events, and Server-Sent Events is preferred over Long Polling, though any one of them could be used. SignalR automatically chooses the best transport method that's within the capabilities of the server and client. For more information, see the official specification for SignalR Transport Protocols.

Server

    The server is responsible for exposing a SignalR endpoint. The endpoint maps to a Hub or Hub<T> subclass. The server can exist on-premises, in a cloud provider (such as Azure), or with Azure SignalR Service. The server exposes both the hub methods, which can be called from clients, and the events that clients can subscribe to. These are considered remote procedures.

Hub

    In SignalR, a hub is used to communicate between clients and servers. A hub is a high-level pipeline that allows a client and a server to call methods on each other. To this end, SignalR handles the dispatching across machine boundaries automatically. You can think of a hub as a proxy between all connected clients and the server.

Protocols

    The SignalR Protocol is a protocol for a two-way RPC over any message-based transport. Either party in the connection can invoke procedures on the other party, and procedures can return zero or more results or an error. SignalR provides two built-in hub protocols:

• A text protocol that's based on JSON, which is the default.
• A binary protocol that's based on MessagePack, which generally creates smaller messages than JSON does.

    To use the MessagePack protocol, both server and client need to opt in to configuring it, and both server and client have to support it. There's a third hub protocol, called BlazorPack, but it's used exclusively with Blazor-Server applications. It can't be used without the Blazor-Server hosting model.

Users

    A user in the system acts as an individual, but it can also be part of a group. Messages can be sent to groups, and all group members will be notified. A single user can connect from multiple client applications. For example, the same user can use a mobile device and a web browser and get real-time updates on both at the same time.

Groups

    A group consists of one or more connections. The server can create groups, add connections to a group, and remove connections from a group. A group has a specified name, which acts as its unique identifier. Groups serve as a scoping mechanism to help target messages. That is, real-time functionality can be sent only to users within a named group.

Connections

    A connection to a hub is represented by a unique identifier that's known only to the server and client. A single connection exists per hub type. Each client has a unique connection to the server. That is, a single user can be represented on multiple clients, but each client connection has its own identifier.

Clients

    The client is responsible for establishing a connection to the server's endpoint through a HubConnection object. The hub connection is represented within each target platform:

• .NET client: Microsoft.AspNetCore.SignalR.Client.HubConnection
• JavaScript client: @microsoft/signalr.HubConnection
• Java client: com.microsoft.signalr.HubConnection

How ASP.NET Core SignalR works

Servers and the Hub class

    The Hub class is a SignalR server concept. It's defined within the Microsoft.AspNetCore.SignalR namespace and is part of the Microsoft.AspNetCore.SignalR NuGet package. ASP.NET Core web apps that target the Microsoft.NET.Sdk.Web SDK don't need to add a package reference for SignalR, because it's part of the shared framework. In other words, it's already available.

    A Hub is exposed through a route. For example, the https://www.contoso-pizza.com/hubs/orders route could be used to represent an OrdersHub implementation. Through the various hub APIs, authors can define methods and events.

    There are two modalities to expose methods on a hub. You create a subclass of the following types and write methods:

• Hub: A standard hub.
• Hub<T>: A strongly typed generic hub.

When to use ASP.NET Core SignalR

    SignalR provides real-time web functionality. Recall that Contoso Pizza requires a live map for tracking the status and delivery of orders. The loss of sales during peak hours is driving the team to investigate a better solution than client-side polling.

Decision criteria

Knowing when not to choose SignalR is just as important as knowing when to choose it. With real-time web functionality, the users' experience of an app relies on its responsiveness. It's best to understand which portions of an application require real-time updates.

When not to use SignalR

SignalR is only as durable as its underlying connection. That is, if there's cause for concern with the connectivity of a client application, SignalR isn't the best choice.

Another consideration is the scalability of SignalR. Depending on the number of concurrently connected clients, your web server could experience resource contention when it reaches its limits. In situations like this, you would likely need to deploy the application to a server farm and use a backplane. Implementing this on your own can be tedious.

Alternatively, you could resolve this problem by using Azure SignalR Service. Or you could help alleviate it by taking advantage of various resiliency and disaster recovery mechanisms.

Valid use cases

    SignalR is not a replacement for traditional HTTP requests. Applications could use SignalR to know when to make specific HTTP requests. In this way, they complement each other.

There are many valid use cases for SignalR. The following list represents good candidates for SignalR:

• Apps that require high-frequency updates from the server:

1. Gaming
2. Social networks
3. Voting
4. Auction
5. GPS apps

• Dashboards and monitoring apps:

1. Company dashboards
2. Live maps
3. Instant sales updates
4. Travel alerts
5. Continuous integration/continuous delivery (CI/CD) pipeline pages

• Collaborative and multi-user interactive apps:

1. Whiteboard apps
2. Team meeting apps
3. Document sharing apps
4. Visual Studio Live Share

• Apps that require notifications:

1. Email apps
2. Chat apps
3. Turn-based games
4. Time series reporting
5. GitHub Actions, issue and pull request systems

Contoso Pizza scenario

    If you're considering a client-side polling solution in the Contoso Pizza live orders map, SignalR could be a viable alternative. As with all programming and architectural decisions, it's critically important to weigh the advantages and disadvantages.