07-25-2019, 02:04 AM
What’s new in Azure SignalR 1.1.0 Preview 1
<div style="margin: 5px 5% 10px 5%;"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2019/06/whats-new-in-azure-signalr-1-1-0-preview-1.png" width="58" height="58" title="" alt="" /></div><div><div class="row justify-content-center">
<div class="col-md-4">
<div><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/whats-new-in-azure-signalr-1-1-0-preview-1.png" width="58" height="58" alt="Avatar" class="avatar avatar-58 wp-user-avatar wp-user-avatar-58 photo avatar-default"></p>
<p>Ken</p>
</div>
</div>
</div>
<div class="entry-meta">
<p>June 3rd, 2019</p>
</p></div>
<p><!-- .entry-meta --> </p>
<p>We just shipped <a href="https://www.nuget.org/packages/Microsoft.Azure.SignalR/1.1.0-preview1-10420">1.1.0 Preview 1</a> 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.</p>
<p>Here is the list of what’s new in this release:</p>
<ul>
<li>Endpoint routing support for ASP.NET Core 3</li>
<li>Use SignalR service in server-side Blazor apps</li>
<li>Server stickiness</li>
</ul>
<h2>Endpoint routing support for ASP.NET Core 3</h2>
<p>For those who are using Azure SignalR, you should be familiar with <code>AddAzureSignalR()</code> and <code>UseAzureSignalR()</code>. These two methods are required if you want to switch your app server from self-hosted SignalR to use Azure SignalR.</p>
<p>A typical Azure SignalR application usually looks like this in Startup.cs (note where <code>AddAzureSignalR()</code> and <code>UseAzureSignalR()</code> are used):</p>
<pre><code class="cs">public void ConfigureServices(IServiceCollection services)
{ ... services.AddSignalR() .AddAzureSignalR(); ...
} public void Configure(IApplicationBuilder app)
{ ... app.UseAzureSignalR(routes => { routes.MapHub<Chat>("/chat"); }); ...
}
</code></pre>
<p>ASP.NET Core 3.0 introduced a new <a href="https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-core-3-0-preview-4/">endpoint routing support</a> which allows routable things like MVC and SignalR to be mixed together in a unified <code>UseEndpoints()</code> interface.</p>
<p>For example, you can call <code>MapGet()</code> and <code>MapHub()</code> in a single <code>UseEndpoints()</code> call, like this:</p>
<pre><code class="cs">app.UseEndpoints(routes =>
{ routes.MapGet("/foo", async context => { await context.Response.WriteAsync("bar"); }); routes.MapHub<Chat>("/chat");
});
</code></pre>
<p>This new syntax is also supported in the latest Azure SignalR SDK so you don’t need to use a separate <code>UseAzureSignalR()</code> to map hubs.</p>
<p>Now your Azure SignalR application looks like this:</p>
<pre><code class="cs">public void ConfigureServices(IServiceCollection services)
{ ... services.AddSignalR() .AddAzureSignalR(); ...
} public void Configure(IApplicationBuilder app)
{ ... app.UseRouting(); app.UseEndpoints(routes => { routes.MapHub<Chat>("/chat"); }); ...
}
</code></pre>
<p>The only change you need to make is to call <code>AddAzureSignalR()</code> after <code>AddSignalR()</code>.</p>
<p>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.</p>
<h2>Use SignalR service in server-side Blazor apps</h2>
<p><a href="https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-3.0">Server-side Blazor</a> 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.</p>
<p><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/whats-new-in-azure-signalr-1-1-0-preview-1-1.png" alt="blazor"></p>
<p>If you look at some server-side Blazor code samples, you’ll see they have a call to <code>MapBlazorHub()</code> to setup the communication channel between client and server.</p>
<pre><code class="cs">app.UseEndpoints(endpoints =>
{ ... endpoints.MapBlazorHub(); ...
});
</code></pre>
<p>The implementation of this method calls <code>MapHub()</code> to create a SignalR hub at server side. Before this release there is no way to change the implementation of <code>MapBlazorHub()</code> to use SignalR service. Now if you call <code>AddAzureSignalR()</code>, <code>MapBlazorHub()</code> will also use SignalR service to host the hub instead of hosting it on the server.</p>
<p>Please follow these steps to change your server-side Blazor app to use SignalR service:</p>
<ol>
<li>Open your Startup.cs, add <code>services.AddSignalR().AddAzureSignalR()</code> in <code>ConfigureServices()</code>.</li>
<li>Create a new SignalR service instance.</li>
<li>Get connection string and set it to environment variable <code>Azure:SignalR:ConnectionString</code>.</li>
</ol>
<p>Then run your app you’ll see the WebSocket connection is going through SignalR service.</p>
<p>Check out this <a href="https://github.com/aspnet/AzureSignalR-samples/tree/master/samples/ServerSideBlazor">repo</a> for a complete code sample.</p>
<h2>Server stickiness</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>To enable this, you just need to set <code>ServerStickyMode</code> to <code>Required</code> in <code>AddAzureSignalR()</code>:</p>
<pre><code class="cs">services.AddSignalR().AddAzureSignalR(options => { options.ServerStickyMode = ServerStickyMode.Required;
});
</code></pre>
<p>Now for any connection, SignalR service will guarantee negotiation and hub invocation go to the same app server (called “server sticky”).</p>
<p>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</code> when using server-side Blazor together with SignalR service.</p>
<p>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</code> 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</code> (this is also the default value) and only enable it when there is a need.</p>
<p>You can refer to this <a href="https://github.com/Azure/azure-signalr/blob/dev/docs/use-signalr-service.md#serverstickymode">doc</a> for more details about server sticky mode.</p>
<div class="authorinfoarea">
<div><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/whats-new-in-azure-signalr-1-1-0-preview-1-2.png" width="96" height="96" alt="Avatar" class="avatar avatar-96 wp-user-avatar wp-user-avatar-96 photo avatar-default"></div>
<div>
<h5><a class="no-underline" aria-label="Ken Chen" target="_blank" href="https://devblogs.microsoft.com/aspnet/author/kenchenmicrosoft-com/" rel="noopener noreferrer">Ken Chen</a></h5>
<p>Principal Software Engineering Manager</p>
<p><strong>Follow Ken</strong> <a class="no-underline stayinformed" aria-label="Ken Chen Twitter profile" target="_blank" href="https://twitter.com/chenkennt" rel="noopener noreferrer"><i class="fa fa-twitter"></i></a><a class="no-underline stayinformed hvr-pop" aria-label="Ken Chen RSS Feed" target="_blank" href="https://devblogs.microsoft.com/aspnet/author/kenchenmicrosoft-com/feed/" rel="noopener noreferrer"></a></p>
</p></div>
</p></div>
</div>
<div style="margin: 5px 5% 10px 5%;"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2019/06/whats-new-in-azure-signalr-1-1-0-preview-1.png" width="58" height="58" title="" alt="" /></div><div><div class="row justify-content-center">
<div class="col-md-4">
<div><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/whats-new-in-azure-signalr-1-1-0-preview-1.png" width="58" height="58" alt="Avatar" class="avatar avatar-58 wp-user-avatar wp-user-avatar-58 photo avatar-default"></p>
<p>Ken</p>
</div>
</div>
</div>
<div class="entry-meta">
<p>June 3rd, 2019</p>
</p></div>
<p><!-- .entry-meta --> </p>
<p>We just shipped <a href="https://www.nuget.org/packages/Microsoft.Azure.SignalR/1.1.0-preview1-10420">1.1.0 Preview 1</a> 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.</p>
<p>Here is the list of what’s new in this release:</p>
<ul>
<li>Endpoint routing support for ASP.NET Core 3</li>
<li>Use SignalR service in server-side Blazor apps</li>
<li>Server stickiness</li>
</ul>
<h2>Endpoint routing support for ASP.NET Core 3</h2>
<p>For those who are using Azure SignalR, you should be familiar with <code>AddAzureSignalR()</code> and <code>UseAzureSignalR()</code>. These two methods are required if you want to switch your app server from self-hosted SignalR to use Azure SignalR.</p>
<p>A typical Azure SignalR application usually looks like this in Startup.cs (note where <code>AddAzureSignalR()</code> and <code>UseAzureSignalR()</code> are used):</p>
<pre><code class="cs">public void ConfigureServices(IServiceCollection services)
{ ... services.AddSignalR() .AddAzureSignalR(); ...
} public void Configure(IApplicationBuilder app)
{ ... app.UseAzureSignalR(routes => { routes.MapHub<Chat>("/chat"); }); ...
}
</code></pre>
<p>ASP.NET Core 3.0 introduced a new <a href="https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-core-3-0-preview-4/">endpoint routing support</a> which allows routable things like MVC and SignalR to be mixed together in a unified <code>UseEndpoints()</code> interface.</p>
<p>For example, you can call <code>MapGet()</code> and <code>MapHub()</code> in a single <code>UseEndpoints()</code> call, like this:</p>
<pre><code class="cs">app.UseEndpoints(routes =>
{ routes.MapGet("/foo", async context => { await context.Response.WriteAsync("bar"); }); routes.MapHub<Chat>("/chat");
});
</code></pre>
<p>This new syntax is also supported in the latest Azure SignalR SDK so you don’t need to use a separate <code>UseAzureSignalR()</code> to map hubs.</p>
<p>Now your Azure SignalR application looks like this:</p>
<pre><code class="cs">public void ConfigureServices(IServiceCollection services)
{ ... services.AddSignalR() .AddAzureSignalR(); ...
} public void Configure(IApplicationBuilder app)
{ ... app.UseRouting(); app.UseEndpoints(routes => { routes.MapHub<Chat>("/chat"); }); ...
}
</code></pre>
<p>The only change you need to make is to call <code>AddAzureSignalR()</code> after <code>AddSignalR()</code>.</p>
<p>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.</p>
<h2>Use SignalR service in server-side Blazor apps</h2>
<p><a href="https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-3.0">Server-side Blazor</a> 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.</p>
<p><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/whats-new-in-azure-signalr-1-1-0-preview-1-1.png" alt="blazor"></p>
<p>If you look at some server-side Blazor code samples, you’ll see they have a call to <code>MapBlazorHub()</code> to setup the communication channel between client and server.</p>
<pre><code class="cs">app.UseEndpoints(endpoints =>
{ ... endpoints.MapBlazorHub(); ...
});
</code></pre>
<p>The implementation of this method calls <code>MapHub()</code> to create a SignalR hub at server side. Before this release there is no way to change the implementation of <code>MapBlazorHub()</code> to use SignalR service. Now if you call <code>AddAzureSignalR()</code>, <code>MapBlazorHub()</code> will also use SignalR service to host the hub instead of hosting it on the server.</p>
<p>Please follow these steps to change your server-side Blazor app to use SignalR service:</p>
<ol>
<li>Open your Startup.cs, add <code>services.AddSignalR().AddAzureSignalR()</code> in <code>ConfigureServices()</code>.</li>
<li>Create a new SignalR service instance.</li>
<li>Get connection string and set it to environment variable <code>Azure:SignalR:ConnectionString</code>.</li>
</ol>
<p>Then run your app you’ll see the WebSocket connection is going through SignalR service.</p>
<p>Check out this <a href="https://github.com/aspnet/AzureSignalR-samples/tree/master/samples/ServerSideBlazor">repo</a> for a complete code sample.</p>
<h2>Server stickiness</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>To enable this, you just need to set <code>ServerStickyMode</code> to <code>Required</code> in <code>AddAzureSignalR()</code>:</p>
<pre><code class="cs">services.AddSignalR().AddAzureSignalR(options => { options.ServerStickyMode = ServerStickyMode.Required;
});
</code></pre>
<p>Now for any connection, SignalR service will guarantee negotiation and hub invocation go to the same app server (called “server sticky”).</p>
<p>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</code> when using server-side Blazor together with SignalR service.</p>
<p>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</code> 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</code> (this is also the default value) and only enable it when there is a need.</p>
<p>You can refer to this <a href="https://github.com/Azure/azure-signalr/blob/dev/docs/use-signalr-service.md#serverstickymode">doc</a> for more details about server sticky mode.</p>
<div class="authorinfoarea">
<div><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/whats-new-in-azure-signalr-1-1-0-preview-1-2.png" width="96" height="96" alt="Avatar" class="avatar avatar-96 wp-user-avatar wp-user-avatar-96 photo avatar-default"></div>
<div>
<h5><a class="no-underline" aria-label="Ken Chen" target="_blank" href="https://devblogs.microsoft.com/aspnet/author/kenchenmicrosoft-com/" rel="noopener noreferrer">Ken Chen</a></h5>
<p>Principal Software Engineering Manager</p>
<p><strong>Follow Ken</strong> <a class="no-underline stayinformed" aria-label="Ken Chen Twitter profile" target="_blank" href="https://twitter.com/chenkennt" rel="noopener noreferrer"><i class="fa fa-twitter"></i></a><a class="no-underline stayinformed hvr-pop" aria-label="Ken Chen RSS Feed" target="_blank" href="https://devblogs.microsoft.com/aspnet/author/kenchenmicrosoft-com/feed/" rel="noopener noreferrer"></a></p>
</p></div>
</p></div>
</div>