SignalR is an open-source Microsoft ASP.NET library that enables realtime asynchronous communication between server-side and client-side web applications.
SignalR provides APIs for building server-to-client realtime remote procedure calls (RPC) that can enable JavaScript functions in client browsers to be invoked from the server .NET code. SignalR can be used to transmit messages to an individual connected client, a group of connected clients, or to all connected clients concurrently.
SignalR is a good candidate for dashboards, monitoring, job progress, realtime forms, gaming, and apps that require notifications, social networks, emails, and games. It also allows for scale-out using Azure SignalR Service or Redis backplane and can scale to thousands of users using third-party scale-out providers.
History
SignalR was created by David Fowler and Damian Edwards in July 2011. It started as an open-source project and attracted other developers to contribute to it. It was later adopted and released as part of the ASP.NET project in 2013.
Prior to the development of SignalR, the WebSocket protocol was not supported on most web browsers, so developers used methods like AJAX polling to achieve realtime communication for web applications. SignalR solved this problem by providing client and server-side libraries to facilitate realtime communication for ASP.NET and thereby abstracting the complexities of the underlying technologies used.
At the time SignalR was created, lots of web applications made use of jQuery, so the JavaScript client for SignalR depended on jQuery to work. By 2018, with the emergence of frontend frameworks and libraries like Angular, React, and Vue, the SignalR team rewrote SignalR from scratch. It was rewritten in plain JavaScript, and it no longer had to depend on jQuery. SignalR was also made extensible so it would be easier to add new transport technologies that may surface in the future.
SignalR Core Components
SignalR uses hubs to communicate between clients and servers. A SignalR hub enables connected servers and clients to invoke methods on each other. It's a high-level pipeline that was built upon the HubConnection API. A SignalR HubConnection is a connection that enables hub methods to be called on a SignalR server. The pipeline also allows passing heavily typed parameters on methods, thus enabling model binding. This means you can define methods on the server and call them on the client, and vice versa.
Transports
SignalR supports the following transport protocols for handling realtime communication
Websocket
Server-Sent Events
Long polling
SignalR by default uses the WebSocket transport protocol in managing realtime communication between server and client, but if for some reason the client or server does not support WebSocket, then SignalR falls back to using Server-Sent Events or Long Polling. The process of choosing or picking which transport technology to use is called transport negotiation.
SignalR negotiates the transport protocol to be used for realtime communication based on the server and client capabilities. You can choose to manually specify the transport protocol SignalR uses to achieve realtime communication, thereby eliminating the time it would take for SignalR to negotiate a transport protocol to be used.
The code below is an example of how to specify what transport is to be used for server-client communication. The code demonstrates WebSocket as the main transport and Server-Sent Events as a fallback.
connection.start({ transport: ['webSockets', 'serverSentEvents'] });
Automatic Reconnections
SignalR is as durable as the connection, so if your connection is broken then your SignalR connection from the client-server gets disconnected as well. Using the withAutomaticReconnect method built on top of the HubConnectionBuilder, SignalR JavaScript clients can be configured to automatically reconnect when an interruption occurs. Automatic reconnections are not enabled by default, so you have to enable them yourself.
Scale-Out
When wanting to scale apps built with SignalR by adding new servers, a common issue is being able to broadcast messages to all clients because clients might be connected to different servers. To address this, SignalR ships with built-in support for scale-out using Redis backplane. A backplane enables multiple instances of your SignalR application to communicate with each other regardless of which instance the clients are connected to.
Alternatively, Azure SignalR Service is another solution (hosted by Microsoft) which lets you scale-out with only minimal code changes.
Resources
ASP.NET Core SignalR JavaScript client
Differences between SignalR and ASP.NET Core SignalR
Recommended Articles
Django Channels alternatives
What are some WebSocket-based alternatives to Django Channels for building realtime functionality such as instant chat and collaboration apps?
FeathersJS Deep Dive
An examination of the FeathersJS framework and its realtime functionality — what it is, setup, limitations.
Guide to Django Channels: What it is, pros and cons and use cases
Discover how Django Channels can be used to power realtime experiences like chat and multiplayer collaboration, its pros and cons, and suitable alternatives.