Search code examples
asp.net-coreblazorblazor-server-side

.NET 8 Blazor Server - blazor.web.js vs blazor.server.js Questions


Previous to .NET 8, Blazor Server apps included blazor.server.js. With .NET 8, the recommendation from Microsoft is to switch from blazor.server.js to blazor.web.js.

I attempted that in my .NET 8 Blazor Server Interactive app, but experienced SignalR errors

enter image description here

Switching back to blazor.server.js has appeared to be more stable

enter image description here

Our Blazor Server apps are hosted on IIS and are behind a load balancer. We do not currently have sticky sessions enabled, but the following logic has seemed to have worked around not having sticky sessions enabled in the past:

<script src="_framework/blazor.server.js" autostart="false"></script>
<script>
    Blazor.start({
        configureSignalR: function (builder) {
            builder.withUrl("/_blazor", {
                skipNegotiation: true,
                transport: 1
            });
        }
    });
</script>

My questions are

  1. Is it still safe to use blazor.server.js in a .NET 8 Blazor Server Interactive only application? Will blazor.server.js get removed in the future?
  2. Is configuring SignalR with skipNegotiation: true and transport: 1 sufficient for working around not having sticky sessions enabled?

Solution

  • The Blazor team recommends upgrading Blazor Server apps to the Blazor Web App model when upgrading to .NET 8 so you can take advantage of the new features, but it's not required. Blazor Server is still fully supported in .NET 8 and you can upgrade an existing Blazor Server app to .NET 8 without making any additional code changes. If you do choose to migrate your Blazor Server app to the Blazor Web App model, then you'll need to make some code changes to your app in addition to switching to the new blazor.web.js script.

    Blazor Server requires sticky sessions because it's a stateful model. If a client needs to reconnect, it should reconnect to the same server so that it reconnects to the same circuit state. The SignalR settings to skipNegotiation and set the transport will only enforce the use of WebSockets and won't facilitate connection back to the same server and circuit state. So, when using a load balancer with a Blazor Server app you'll still want to enable session affinity.