2

I'm reading the very limited information about Azure SignalR service as well as the quick start guide and want to make sure I'm understanding this correctly.

We still seem to have a hub and if I understand this correctly, the function of Azure SignalR service is to simply push the messages to connected clients.

In my case, I store the history of chat so by hitting the hub first, I'm able to still use my backend logic to persist chat history or do any other processing that I may want. Then simply allow Azure SignalR service to push the data to connected clients.

The main benefit seems to be handling the scaling of the service.

Am I getting this right?

Arie Xiao
  • 13,909
  • 3
  • 31
  • 30
Sam
  • 26,817
  • 58
  • 206
  • 383

2 Answers2

3

Yes, you are totally right.

You will use exactly the same API of ASP.NET Core SignalR to write your business logics, which means you can persist whatever you want when the messages from clients hit your hubs.

Azure SignalR Service will be the underlying transport between your app server and connected clients. For example, when you want to broadcast messages to all your clients, you actually only send one message to Azure SignalR Service and the service will broadcast the message to all clients for you. So that you don't have to worry about the scale-out. Azure SignalR Service will handle the scaling-out for you.

KevinZhaoMSFT
  • 61
  • 3
  • Thanks. Is it safe to assume Azure SignalR service also gives me the ability to push to certain groups? So not a broadcast all but broadcast to a group scenario. – Sam May 09 '18 at 20:53
  • @Sam Yes. SignalR has the concept of the group. You can add clients to any group and send messages only to a certain group. – KevinZhaoMSFT May 09 '18 at 20:56
  • Great! So essentially there’s no difference in behavior whether I use SignalR locally within my app or use the Azure SignalR service. – Sam May 09 '18 at 20:58
  • @Sam Correct! You can develop locally with ASP.NET Core SignalR and easily move to Azure SignalR Service when deploying to Azure. – KevinZhaoMSFT May 09 '18 at 21:03
  • I have a follow up question about the JavaScript files. Are they served by the Azure SignalR service and not my app? I think users are essentially connecting to the Azure SignalR service for real time content and not to my app. I think my app continues to provide all other functionality and the hub serves as the conduit to SignalR service but all real time content gets pushed by the service and not my app. That's why I'm thinking the JS files are served by the service and not my app. Is this how it works? – Sam May 12 '18 at 06:48
  • No, they don't. Your application serves them (or they come from a cdn) – davidfowl May 12 '18 at 21:53
1

You understand correctly.

SignalR is not yet ready for production (when speaking about ASP.NET Core), SignalR for ASP.NET MVC has been around for a while (stable).

SignalR consists of 2 pieces: server and client. The server is as you describe: a "hub" that you can use to push information to clients.

On a webpage you load a piece of generated javascript (generated automatically from your hub definitions). Basically you let your website visitors (clients) connect to the hub through signalR's mechanism (signalR will choose the proper way to connect depending on the browser), and then 'subscribe' to the different methods you have active in your hub.

The workings are simple: whenever you call code in your hub (can be from clients, or from backend code) communication is automatically handled for you to all subscribed clients.

Note: If you are running this on an azure web app: enable the "always on" setting, and set the "websockets" toggle to "enabled", otherwise you'll see strange behaviour.

Note2: The RC version for signalR core 1.0 has just been released (7th of may 2018) so it might be a while before this software starts becoming stable and available through the public nuget/npm channels.

Erik J.
  • 799
  • 6
  • 19