This website uses cookies on its adverts and sponsored links. By clicking the "Accept" button you are consenting to their use.

Read more

Accept


Mobile Tech Tracker
≡ sections
Coding Courses

Tech Advice

Career Advice

Cybersecurity

Opinions

About

Welcome to Mobile Tech Tracker. Our mission is to help technically-minded people to become better versions of themselves and to help ordinary people to use modern smart technologies to their own advantage.

We can provide consulting or programming training services, including authoring of courses and books. For enquiries, please contact consulting@mobiletechtracker.co.uk.


Why you absolutely need SignalR for ASP.NET development

If you are using ASP.NET Core for web application development, you should get yourself familiar with SignalR library. And once you have, you will be surprised how you used to manage without it.

If you open any modern day web application, from a social media web page to your in-browser email client, there will be a feature that everyone these days takes for granted - the ability to refresh any arbitrary parts of the web page in real time without having to reload the entire page. And this is just the most basic things you can do with SignalR.

Although you don't necessarily need SignalR to achieve an asynchronous real-time data transfer between clients and the servers, SignalR is by far the best way of implementing it in ASP.NET. Let's find out why is it so.


What SignalR does

SignalR is a library that was published by Microsoft as one of the modules of ASP.NET Core since version 2.1. Prior to this, it has been available in the .NET Framework-based ASP.NET classic. The more recent .NET Core version is a complete rewrite of it, rather just a mere port of the original code.

The key purpose of SignalR is to enable two-way asynchronous real-time communication between the client and the server. So, instead of a classic request-response model where clients have to send a request to the server to get some data returned from it in a response, SignalR just enables a persistent connection, which enables the data to travel both way at any point in time.

The best way of doing so is to use WebSocket protocol, which SignalR uses under the hood by default. Under some circumstances, WebSocket cannot be used. This, however, isn't an issue for SignalR. It will just use a different communication mechanism instead.

Modern ASP.NET Core SignalR version uses server-sent events if WebSocket cannot be used for any reason. If server-sent events aren't available either, SignalR can fall back to long polling, which is not as efficient, but is available everywhere.

ASP.NET classic version of SignalR also has forever frame as one of its communication mechanisms. However, as this technology has limited availability and is pretty much obsolete, it hasn't been made available on the ASP.NET Core version.

As well as using these transport mechanisms in a fallback hierarchy, SignalR client can explicitly choose which one to use. So, if you, for whatever reason, need to use long polling even when WebSocket is enabled, you can do so.

ASP.NET Core version is the one we will focus on in this article; although most of the benefits apply equally well to the ASP.NET classic version. So, let's jump to the reasons why SignalR is way better than any alternatives you may encounter.


All complexity is abstracted away

If you want to create your own implementation of a WebSocket server, good luck. Of course, it is doable, but there are way too many things to take care of.

For example, you will probably have to split your messages into streams of bytes of the equal size and send them in sequence. So, your code will probably look something like this:

WebSockets C# code example

Not very readable, is it?

So, already there are some decision to make. What is the size of each byte array? And how do you clean up unused elements from the last byte array to reconstruct the message into its original form? This is why both your client and your server will have to have something like this:

WebSockets decoding example

And what do you do if one of the message chunk fails to get transmitted? Do you start over, or do you just retry for those arrays that haven't been transmitted yet?

And what about a scenario where you can't even use WebSocket? In this case, you will have to write quite a lot of extra code to handle other transport mechanisms.

With SignalR, none of these will matter. The code is so simple that it looks almost like you can directly call methods on the server from a client and vice versa.

For example, this is a method that you can have on the server:

SignalR hub method example

This is how you can call it from a web page:

SignalR JavaScript call

This is how you can call it from a non-browser client:

SignalR C# call

Yes, SignalR works with any types of client and not necessarily web pages. We will cover more of this later.

This is an example of a client method that the above server method calls:

SignalR JavaScript method

And this is the same method on a non-browser client:

SignalR C# method

Of course, remote method calling is not what actually happens under the hood. But all complex implementation details have been abstracted away, so this is not something you, as a developer, will have to worry about.

Likewise, the code will be exactly the same regardless of which transport mechanisms you use. Of course, your WebSocket network traffic will look different from what will happen if you'll use long polling. But the code will still look the same regardless.


No more need for AJAX

Back in the days, AJAX was a standard way of making partial updates to a web page by asynchronously retrieving some data chunks from the server. This was especially popular when jQuery was used everywhere.

AJAX was completely fine when all you needed was to retrieve data from the server when some user-initiated action happened on the web page. But what if you needed to retrieve new data as soon as it becomes available?

With AJAX, you would have to implement some sort of logic that queries the server at regular intervals. This would make real-time applications, such as chat, fairly inefficient and not necessarily fully synchronised in time.

With SignalR, you won't have to do any of this. Your client will automatically receive the update as soon as the data is available. In a chat scenario, which is often used as a SignalR example, all participants will receive the message as soon as someone posts it.

And let's not forget that every request in AJAX is a fully fledged HTTP request with headers and handshake. This uses quite a bit of network bandwidth.

With SignalR, however, the persistent connection is just kept open, so, except for an occasional heartbeat data transfer that is small in size, it's pretty much only the data that gets transmitted with very little in terms of extra payload.


Works with any types of client

Browser-based clients are a common use case for SignalR. However, in real world, not all the clients are browser-based. For example, you may have some IoT devices that communicate with the centralised hub on the server.

SignalR provides an official support for .NET, Java and JavaScript clients, the latter of which doesn't necessarily have to be browser-based. And, on top of that, any client that supports WebSocket, Server-sent Events or long polling in their pure form can be made compatible with SignalR server.

For instance, this online course provides an example of how to use a pure WebSocket client with your SignalR hub.

As these transport mechanisms can be implemented in any programming language on any platform, your SignalR client can be written in any programming language on any platform.


Can be scaled out very easily

SignalR has a number of in-built ways of scaling your application out. This would be extremely difficult if you would have to do it on your own for applications with persistent real-time connection. For example, if you want to send a message from a particular client to all clients in a particular group, how would you identify all required clients, if they are connected to different nodes in a load-balanced cluster?

With SignalR, there is Redis-based backplane mechanism, which allow all nodes in the cluster to notify each other in real time. Therefore your application code will be exactly the same, regardless of whether you are running a single instance of it or many instances. They will still act like a single application.

Another way of scaling out your SignalR application is to use Azure SignalR Service. In this case, you will just delegate all load balancing to Azure cloud, which will automatically scale it based on the demand. In this case, you will just have to pay more if people use it more.


Used in other parts of ASP.NET Core

The final feature of SignalR that I would like to cover is that it is integrated into other parts of ASP.NET Core, so it will be useful to know, even if you don't intend to use it directly. For example, it is used to facilitate communication between the client and the server in server-side Blazor.

As well as this, it is used inside some premium Microsoft products. Visual Studio is one of them.


Wrapping up

If you, as an ASP.NET developer, will ever need to establish an asynchronous real-time two-way communication between the client and the server (which you definitely will), SignalR is the library you will need to get yourself familiar with.

And it will do so in a very convenient way by abstracting away all the complex implementation details, so your client and the server will look like they are just calling each other's methods directly.

SignalR makes AJAX obsolete and improves your network bandwidth usage in the process. And you can write your client code in any programming language on any platform.

SignalR can be scaled out extremely easily. You can do so either in your own code by sharing a backplane between the application instances or by utilising Azure SignalR Service.

Finally, SignalR is used extensively by Microsoft itself, both in its programming frameworks and its premium products. So, if it's good for Microsoft, it is certainly good for you.

All the concepts we talked about in this article are taught in this online course on Udemy. For any other programming courses that we've published, please visit this page.

Happy hacking!



Written by

Posted on 5 Jul 2019

Fiodar Sazanavets is a full stack software developer with several years of experience working in various industries. In his professional career, he has mainly worked with a number of different technologies from Microsoft stack, both back-end and front-end, and Java for Android. The main Fiodar's speciality is .NET. As well as being an experienced programmer, Fiodar has an Honours degree in Environmental Biology and a Masters degree in Environmental Informatics.



Tech Advice Articles


Applying clustering on OpenLayers map

Applying clustering on OpenLayers map


Pros and cons of Blazor for web development

Pros and cons of Blazor for web development


Web GIS: Making modal pop-up on an OpenLayers map

Web GIS: Making modal pop-up on an OpenLayers map


Using .NET Core SDK projects in .NET Framework

Using .NET Core SDK projects in .NET Framework


Learning .NET Core from scratch

Learning .NET Core from scratch


Playing audio on .NET Core with NetCoreAudio

Playing audio on .NET Core with NetCoreAudio


Building .NET Core sound application - part 3

Building .NET Core sound application - part 3


Building .NET Core sound application - part 2

Building .NET Core sound application - part 2


Building .NET Core audio application - part 1

Building .NET Core audio application - part 1


Building .NET Core desktop application

Building .NET Core desktop application


Share this:

Facebook Google LinkedIn Twitter Become a Patron!


More from Tech Advice











Privacy Policy

© Mobile Tech Tracker. All rights reserved. Unauthorised copying of any of this website's content is prohibited under international law.

For any queries, comments or suggestions, please write to info@mobiletechtracker.co.uk.