What’s SignalR and Why Should we use It?

SignalR is a set of server and client libraries that facilitate simple, real-time, two-way communications between server and client. Not only can the client initiate contact with the server, as is the case in Web development, but the server can also contact the client. Those aren’t just simple HTTP responses, either. These are actual method calls from server to client, like push technology. Clients can even contact other clients through the SignalR server-side component. All this is possible because SignalR creates a persistent connection between the server and client.

Everyone wants to create modern software—and it doesn’t get any more modern than full duplex communications. There are several reasons to use SignalR. Its ease of use for writing Web sites and apps is one good reason. Another is if you need live communication in your software. In those instances, SignalR is the way to go. You could do it yourself using any number of techniques, such as WebSockets or AJAX polling. However, you’d have to rewrite all the groundwork the SignalR team has already done. This groundwork is fairly expansive and includes several key features:

• Transport negotiation: SignalR detects the best transport to get as close to real-time communications as possible. It uses WebSockets by default, as that’s the fastest and most modern way to write real-time Web apps. Automatic transport management is behind the idea of real-time communication in SignalR. It negotiates a transport for each client as it connects.
• SignalR server host: You can choose between lightweight self-hosting anywhere, including non-Microsoft platforms, or hook SignalR into the IIS pipeline.
• Client-side libraries: Including JavaScript, the Microsoft .NET Framework and Windows Store libraries.
• JavaScript proxy: This provides a way to call methods in remote locations in JavaScript, while developing as if all code is running in the same process on the same machine.
• Security: SignalR hooks into existing ASP.NET security models, and supports many popular third-party security providers such as Microsoft Live, OpenAuth, Google, Facebook and Twitter.

Web developers traditionally write code according to the request/response model of HTTP. There’s nothing inherently bad with this, but it lacks the primary benefit of SignalR—a persistent connection between server and client. In HTTP, you make a request, get a response and then you’re done. In a real-time scenario, the pipeline stays open between the server and client. This lets you create richer and better UXes that feel alive and connected.

In SignalR, there are two layers of abstraction over the low-level transports—hubs and persistent connections. This article will cover just hubs for the sake of brevity. Hubs are the higher-level API that’s the “incredibly simple” part of SignalR. Persistent connections take more time and effort to code, and SignalR uses them as the basis for hubs. You’ll generally use hubs for most of your activities, unless you have good reasons to do otherwise.