This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.
1 - Introduction to SignalR
If you are a software developer who builds web, mobile or internet of things (IoT) applications, you will appreciate how important it is for your applications to have the ability to communicate with the server asynchronously and in real time. Also, you probably realize that the standard request-response model of communication isnt fully suitable for modern apps. Sometimes, your client application (whether its a web page, a mobile app or a service on an IoT device) needs to be able to receive a real-time update from the server that was actually triggered by an event on the server and not by a client request.
We see this functionality everywhere. When you use a messenger app, you would expect to receive a message as soon as someone has sent you one. When you control your IoT devices, you expect them to respond to your commands as soon as you trigger them.
But the problem with such functionality is that the said functionality is not always easy to implement. You could still use the classic request-response model and just carry on sending requests to the server until you receive a right type of response. But this would be wasteful. And, if your client application has limited bandwidth to work with, you may not even be able to do it at all, as continuous requests to the server may end up using up the entire bandwidth really quickly. As well as all of this, your code to implement such a behavior would probably be way more complicated than it should be.
There is also an alternative - WebSocket
protocol. This is a much better solution. The protocol was specifically designed to enable two-way communication between the client and the server. All you have to do is establish a connection between the two endpoints. And, as long as this connection is live, the messages can flow both ways. As well as sending any arbitrary message from the client to the server, you can also send messages from the server to the client. And, on top of this, WebSocket protocol is very efficient. Maintaining the connection doesnt use much bandwidth at all.
However, WebSocket doesnt come without its own problems. Its far from being the easiest thing to work with. Out of the box, WebSocket protocol uses raw data instead of human-readable abstractions. It transmits messages by using raw bytes. So, its up to you to do all the assembling and disassembling of messages. Its also up to you to monitor the state of the connection. The WebSocket code youll have to write will probably look similar to this, which is neither very intuitive nor easily readable:
Figure 1.1 - WebSocket implementation example
But if you are .NET developer, you wont have to deal with any of this. Enabling efficient real-time two-way communication will almost be as easy as making classes inside a single application call each others methods. And all of this was made possible with a help of a library called SignalR
, which is one of the in-built libraries of AS.NET Core.
What makes SignalR so great
SignalR is a library that is incredibly easy to implement compared to the alternatives. Using this library is just as easy as writing remote procedure calls. You will have some endpoint methods on your server that are just bog-standard C# methods. And, as long as you specify the methods of the same names on the client and put the expected parameters into them, the connection will be made and the method will be triggered.
Same applies the other way round. Your client will have event listeners with arbitrary names. And, as long as you spell the name of the listener correctly in your server-side code and apply expected data types as parameters, the listener on the client will be triggered.
For example, your server-side method may look like this:
Figure 1.2 - Server-side SignalR method
And your client code that will trigger this method may look like this:
Figure 1.3 - Client-side SignalR method invocation
Under the hood, SignalR library uses WebSocket protocol. But you, as a developer, dont have to worry about implementation details of it. Those are abstracted away to make things as convenient for you as possible.
But WebSocket is not the only protocol that SignalR uses, even though it is the default protocol it will try to use. It just happens that, although there arent many use cases where you wont be able to use WebSocket, occasionally you may encounter such a situation. And this is why SignalR comes with two fallback protocols, which are server-sent events and long polling. The fallback order is as follows:
- If possible, use WebSocket
- If WebSocket cant be used, use server-sent events
- If server-sent events cant be used, use long polling
Long polling is the least efficient protocol of them all. This is where the client sends a standard HTTP request to the server and just waits until the response is sent back. This is why you wont be using this protocol until absolutely necessary. But the main benefit of it is that absolutely any system that supports HTTP supports long polling.
If you need to, you can even explicitly specify the protocol in the client configuration. But in most cases, you wont have to. But even if you do, the choice of the protocol will have zero impact on the way you write your code. All your code will be identical regardless of the protocol being used.
Example use cases for SignalR
SignalR is a perfect library to be used in any scenarios where clients need to receive real-time updates from the server or there is high a high frequency of data exchange between the client and the server. As per the official documentation, the following are some of the examples where SignalR is an ideal library to use:
- High frequency data updates: gaming, voting, polling, auction.
- Dashboards and monitoring: company dashboard, financial market data, instant sales update, multi-player game leader board, and IoT monitoring.
- Chat: live chat room, chat bot, on-line customer support, real-time shopping assistant, messenger, in-game chat, and so on.
- Real-time location on map: logistic tracking, delivery status tracking, transportation status updates, GPS apps.
- Real time targeted ads: