I have been following Dino Esposito’s SignalR series from the last few MSDN Magazine editions. In the May edition of the Magazine, Dino talked about the subtle details of ASP.Net Core SignalR. It is an excellent read, and it covers the topic in a much better and concise manner than I will ever be able to describe.

In his latest article, Dino discussed the various use cases of SignalR. If you have been watching the Azure space closely, then you must have noticed that a new service named Azure SignalR Service joined the Azure family. I thought of implementing one of the use cases that Dino discussed in the articles using the Azure SignalR Service.

Azure SignalR Service

Azure SignalR Service sits between your clients and your backend services so that you don’t have to implement workarounds for scalability, performance, and availability. If you were to maintain SignalR backend yourself, you would soon run into scalability issues when a large number of persistent WebSocket connections are opened with your application. The Azure SignalR Service sits like a giant computer in front of your backend systems which is capable of maintaining a large number of persistent connections open at all times. The following is the architecture of a simple Azure SignalR Service based system.

Another critical aspect of the architecture is that the backend system need not always be a WebAPI or any other Web Application. You can easily build an Azure Function that communicates with the clients asynchronously. Having the flexibility of choosing the backend systems is helpful in scenarios such as progress monitoring, where a backend system can keep updating the clients on the progress made with the requested operation.

#azure signalr #count online users #service