Matthew Chestnut is a Senior Consultant at ThreeWill. He has over 25 years of software development experience around enterprise and departmental business productivity applications. He has a proven track record of quality software development, on-budget project management and management of successful software development teams.
Azure SignalR Service and .NET Core
On a recent project, we turned to Azure SignalR for its ability to periodically send the status of long-running processes to our Angular-based single-page application. These long-running processes execute in a couple of different contexts:
- In our middle-tier WebAPI layer
- In an external service brokered by Azure Service Bus
Different Versions
When we first began looking at SignalR, we soon realized there are different versions of the product that, while working similarly, have slightly different APIs and methods of instantiation; see “Differences between ASP.NET SignalR and ASP.NET Core SignalR”
- NET SignalR
- NET Core SignalR
- Azure SignalR Service
The Version We Decided On
Because we were using .NET Core we realized that ASP.NET Core SignalR was the version we needed to implement. And, since we are leveraging Azure for other services, we investigated “What are the benefits using Azure SignalR Service?” We decided to use Azure SignalR Service for the following reasons:
- Native ASP.NET Core support: SignalR Service provides native programming experience with ASP.NET Core and ASP.NET.
- Handle large-scale client connections: SignalR Service is designed for large-scale real-time applications. SignalR Service allows multiple instances to work together to scale to millions of client connections.
- Remove the burden to self-host SignalR: Compared to self-hosted SignalR applications, switching to SignalR Service will remove the need to manage back planes that handle the scales and client connections.
- Ease of integration with Azure Web Jobs: With minimal code, we are able to send messages back to the client based on Service Bus events monitored by Web Job functions.
Helpful References
In our project, we only needed “server to client”, i.e. one-way, communication and messaging. The Angular-based client application needed to be configured to receive these push notifications. These blog posts got us started in the right direction:
- “Add real-time web functionality to Angular application using ASP.NET Core SignalR, Azure SignalR service and Azure SignalR Service bindings for Azure Functions 2.0“
- “Getting Started With SignalR, .NET Core 2.1 And Angular“
For us, most of the code for implementing SignalR was on the client-side, as that is where we needed to process and render the inbound messages. For the Azure Web Job and Azure SignalR Service, it was primarily an exercise in configuration.
