shutterstock_1435070885.jpg

Why We Decided to Use Azure SignalR Service

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:

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.

Matthew ChestnutWhy We Decided to Use Azure SignalR Service

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.