What’s new in Azure SignalR 1.1.0 Preview 1

What’s new in Azure SignalR 1.1.0 Preview 1 - Printable Version

+- Sick Gaming (https://sickgaming.net)
+-- Forum: Programming (https://sickgaming.net/forum-76.html)
+--- Forum: C#, Visual Basic & .NET (https://sickgaming.net/forum-79.html)
+--- Thread: What’s new in Azure SignalR 1.1.0 Preview 1 (/thread-90686.html)

What’s new in Azure SignalR 1.1.0 Preview 1 - xSicKxBot - 06-05-2019

What’s new in Azure SignalR 1.1.0 Preview 1

Ken

June 3rd, 2019

We just shipped 1.1.0 Preview 1 of Azure SignalR Service SDK to support some new features in ASP.NET Core 3.0, including endpoint routing and server-side Blazor. Let’s take a look how you can use them in your Azure SignalR application.

Here is the list of what’s new in this release:

Endpoint routing support for ASP.NET Core 3
Use SignalR service in server-side Blazor apps
Server stickiness

Endpoint routing support for ASP.NET Core 3

For those who are using Azure SignalR, you should be familiar with

Code:
AddAzureSignalR()

and

Code:
UseAzureSignalR()

. These two methods are required if you want to switch your app server from self-hosted SignalR to use Azure SignalR.

A typical Azure SignalR application usually looks like this in Startup.cs (note where

Code:
AddAzureSignalR()

and

Code:
UseAzureSignalR()

are used):

Code:
public void ConfigureServices(IServiceCollection services)
{ ... services.AddSignalR() .AddAzureSignalR(); ...
} public void Configure(IApplicationBuilder app)
{ ... app.UseAzureSignalR(routes => { routes.MapHub<Chat>("/chat"); }); ...
}

ASP.NET Core 3.0 introduced a new endpoint routing support which allows routable things like MVC and SignalR to be mixed together in a unified

Code:
UseEndpoints()

interface.

For example, you can call

Code:
MapGet()

and

Code:
MapHub()

in a single

Code:
UseEndpoints()

call, like this:

Code:
app.UseEndpoints(routes =>
{ routes.MapGet("/foo", async context => { await context.Response.WriteAsync("bar"); }); routes.MapHub<Chat>("/chat");
});

This new syntax is also supported in the latest Azure SignalR SDK so you don’t need to use a separate

Code:
UseAzureSignalR()

to map hubs.

Now your Azure SignalR application looks like this:

Code:
public void ConfigureServices(IServiceCollection services)
{ ... services.AddSignalR() .AddAzureSignalR(); ...
} public void Configure(IApplicationBuilder app)
{ ... app.UseRouting(); app.UseEndpoints(routes => { routes.MapHub<Chat>("/chat"); }); ...
}

The only change you need to make is to call

Code:
AddAzureSignalR()

after

Code:
AddSignalR()

.

This will be very useful in the case that SignalR is deeply integrated in your code base or the library you’re using. For example, when you’re using server-side Blazor.

Use SignalR service in server-side Blazor apps

Server-side Blazor is a new way to build interactive client-side web UI in ASP.NET Core 3. In server-side Blazor, UI updates are rendered at server side, then sent to browser through a SignalR connection. Since it uses SignalR, there is a natural need to use Azure SignalR service to handle the SignalR traffic so your application can easily scale.

If you look at some server-side Blazor code samples, you’ll see they have a call to

Code:
MapBlazorHub()

to setup the communication channel between client and server.

Code:
app.UseEndpoints(endpoints =>
{ ... endpoints.MapBlazorHub(); ...
});

The implementation of this method calls

Code:
MapHub()

to create a SignalR hub at server side. Before this release there is no way to change the implementation of

Code:
MapBlazorHub()

to use SignalR service. Now if you call

Code:
AddAzureSignalR()

Code:
MapBlazorHub()

will also use SignalR service to host the hub instead of hosting it on the server.

Please follow these steps to change your server-side Blazor app to use SignalR service:

Open your Startup.cs, add
Code:
services.AddSignalR().AddAzureSignalR()
in
Code:
ConfigureServices()
.
Create a new SignalR service instance.
Get connection string and set it to environment variable
Code:
Azure:SignalR:ConnectionString
.

Then run your app you’ll see the WebSocket connection is going through SignalR service.

Check out this repo for a complete code sample.

Server stickiness

The typical connection flow when using SignalR service is that client first negotiates with app server to get the url of SignalR service, then service routes client to app server.

When you have multiple app servers, there is no guarantee that two servers (the one who does negotiation and the one who gets the hub invocation) will be the same one.

We hear a lot of customers asking about whether it’s possible to make the two servers the same one so they can share some states between negotiation and hub invocation. In this release we have added a new “server sticky mode” to support this scenario.

To enable this, you just need to set

Code:
ServerStickyMode

Code:
Required

Code:
AddAzureSignalR()

Code:
services.AddSignalR().AddAzureSignalR(options => { options.ServerStickyMode = ServerStickyMode.Required;
});

Now for any connection, SignalR service will guarantee negotiation and hub invocation go to the same app server (called “server sticky”).

This feature is very useful when you have client state information maintained locally on the app server. For example, when using server-side Blazor, UI state is maintained at server side so you want all client requests go to the same server including the SignalR connection. So you need to set server sticky mode to

Code:
Required

when using server-side Blazor together with SignalR service.

Please note in this mode, there may be additional cost for the service to route connection to the right app server. So there may be some negative impact in message latency. If you don’t want the performance penalty, there is another

Code:
Preferred

mode you can use. In this mode stickiness is not always guaranteed (only when there is no additional cost to do the routing). But you can still gain some performance benefits as message delivery is more efficient if sender and receiver are on the same app server. Also when sticky mode is enabled, service won’t balance connections between app servers (by default SignalR service balances the traffic by routing to a server with least connections). So we recommend to set sticky mode to

Code:
Disabled

(this is also the default value) and only enable it when there is a need.

You can refer to this doc for more details about server sticky mode.

Ken Chen

Principal Software Engineering Manager

Follow Ken https://devblogs.microsoft.com/aspnet/author/kenchenmicrosoft-com/feed/