What is the difference between classic and serverless mode on Azure SignalR Service?

Question

User-1128090897 posted

I'm trying to wrap my head around the new Azure SignalR Service. I've never used SignalR in any capacity, but it sounds exactly what I'm looking for. I'm just a bit confused about which components are needed when I'm using the Azure SignalR Service.

I see that prior to Azure releasing a SignalR service you had to host your own ASP.NET-based SignalR server. It's my understanding that the new Azure SignalR Service can remove the need for me to code and run my own ASP.NET-based SignalR Server, correct?

In a lot of examples and documentation, I still see, what looks to me like, references to hosting your own ASP.NET-based SignalR server, but that server instead proxies requests through to Azure's SignalR Service? Do I still need my own ASP.NET SignalR server?

On the Azure SignalR Service portal, I see a toggle to change between "Serverless" and "Classic" modes. The default selected mode is one labeled "Default", so I'm unsure which one is truly the default - serverless or classic. What is the difference between Serverless and Classic modes? I assume that Serverless means I no longer need my own ASP.NET SignalR server? I can completely rely on the Azure SignalR Service?

If it is still required that I run my own ASP.NET SignalR server in conjunction with the Azure SignalR Service, then what does the Azure Service alleviate for me?

Answer 1

User-1128090897 posted

I think I found some documentation that really clears up a lot of what I was confused about, located here ...

https://github.com/Azure/azure-signalr/blob/dev/docs/

Answer 2

User61956409 posted

Hi rcoleils2,

The applications that use SignalR scale, managing and scaling a SignalR server can become quite a bit of work, if use Azure SignalR service, developers can focus on building real-time web experiences without worrying about setting up, hosting, scaling, or load balancing SignalR server. For detailed information, please check this blog.

Besides, to implement complex and flexible custom real-time messaging push/broadcast functionality, we still need to create Hub class and write Hub methods.

With Regards,

Fei Han