Building real-time applications isn’t easy. You need tools to synchronize content, pushing information between servers and clients. While technologies like WebSockets or the media layers of WebRTC go some of the way to deliver the underlying protocols that you need, they’re only part of the story.
Introducing SignalR
Microsoft’s ASP.Net introduced SignalR for delivering real-time data over the web. It’s a bi-directional protocol that’s built on top of WebSockets, with a set of APIs that treat it as a remote procedure call. Servers can call procedures on registered clients, while clients can do the same to connected servers. Using SignalR, you can broadcast datato all the clients that are currently connected to a server, or target messages to only one—all at a high frequency.
Because SignalR uses WebSockets, each connection is persistent. There’s no setup and teardown associated with a message, so it can be used in near real-time. It’s also scalable, and by using the ASP.Net version you can work with a very large number of clients indeed. But that does mean having the hardware in place to manage your predicted load, and being ready to add more physical or virtual machines as you need them.
If a WebSocket connection isn’t available, you can either specify an alternate protocol (often using a long HTTP session) or let SignalR negotiate its own fallbacks between client and server. With modern browsers like Google Chrome now predominant, you’re less likely to need a fallback option in your code, but it’s still worth considering if you’re likely to need to support users running old versions of Internet Explorer.
Scaling SignalR on Azure
Setting up and running a SignalR service isn’t hard, but scaling it can be complex. That’s where the new Azure SignalR Service comes into play, offering direct integration with Azure services without having to think about the underlying infrastructure and issues of reliability and availability. Microsoft offers a 99.9 percent SLA, which should cover most options.
Integration with Azure Services also reduces the amount of code you need to write, because you can use Azure Active Directory for authentication and Azure Blobs for storage. For more complex apps, you can use SignalR to feed data from serverless Azure Functions or from Azure Event Hubs and Azure Event Grid to your dashboards, making it a useful tool for internet of things applications or for adding monitoring services to large-scale line of business services.
Moving to Azure SignalR Service from ASP.Net
If you’re already using ASP.Net SignalR, moving to the Azure SignalR Servicecan help with scaling, though you will need to switch your code from the original ASP.Net to ASP.Net Core’s implementation of SignalR. The APIs are different, so this means changing your code; moving to Azure SignalR is not a matter of lifting and shifting existing ASP.Net applications from your servers to Azure. Scaling is handled by adding new SignalR units to an application, with each unit supporting 1,000 clients.
You start by creating an Azure SignalR Service resource in the Azure portal. This is where you’ll name your service, choose resource groups and locations, as well as assigning it to a subscription. Two pricing options are available: free and standard.
The free option is best suited for test and development or for applications that are intended to support a limited number of connections, with support for a single unit with 20 concurrent connections and a limit of 20,000 messages a day. The standard service costs $0.0335 per unit per hour, with as many as 1,000 connections per unit and 1 million messages. You can also scale up to 100 units. Once deployed, you find keys and connection strings in your Azure portal’s SignalR Service settings.
Using SignalR for persistent output connections for serverless applications
Adding SignalR support to Azure Functions gives you a way of adding persistent output to code that only runs when triggered. Instead of having to write code to poll a function for output, or to scan for changes to data that’s managed by a function, you simply receive and process a message that’s handled by Azure SignalR operating as a messaging hub.
To use the service from a function, you need to bind it to your function’s output. At the same time, you also need an input binding to handle connection information from the service. These can take advantage of the REST APIs Microsoft has added to the Azure SignalR Service, which make it accessible from any language with REST support.
SignalR and REST
Currently there are two versions of the API, 1.0 beta and 1.0. Because the beta release supports deprecated APIs that aren’t supported in Version 1.0, it’s best to support only Version 1.0 in your code. This gives you APIs for broadcasting to all connected clients, to a subset group, or to a single user, as well as adding and removing users from groups. In practice, you’re most likely to be sending messages to all clients, using SignalR as a one-way broadcast protocol.
Accessing the SignalR Service APIs over REST requires each header to have a JSON web token, which you generate using your connection string. You also need to confirm its audience (usually your request URL) and the expiry of the token.
Once you’ve set up your function and any SignalR endpoints, triggers are reflected in changes at connected clients. So, for example, if you’re using a function to monitor a Cosmos DB database for specific changes, those changes are displayed in a client dashboard as soon as they’re detected by the function. Because you pay for compute time in seconds—and for most low-volume applications you’re able to stay in the SignalR Service free tier—you should be able to build and run monitoring services in Azure for very little money.
Not every application is suitable for SignalR, but where you need real-time information, it’s worth considering. Most message brokers run as queues, and are designed for reliable messaging operations. By operating as a hub reflecting rapidly changing data, SignalR avoids latenc, while still appearing to clients as a persistent endpoint. It’s a combination that makes it worth considering as part of any large-scale serverless application model.