CODEWITHSUNDEEP
asp.net-coreblazorblazor-server-side
Ryan Buening
Ryan Buening

Reputation: 1660

.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?

Upvotes: 5

Views: 3288

Answers (2)

Daniel Roth
Daniel Roth

Reputation: 151

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.

Upvotes: 7

Chandradev
Chandradev

Reputation: 29

Reasons to avoid blazor.server.js in .NET 8:

Deprecated: Microsoft has officially deprecated blazor.server.js in favor of blazor.web.js. This means it might receive less future development and support, potentially leading to compatibility issues later on.

Limited Functionality: It's designed for Blazor Server apps, not Blazor Server Interactive (which falls under Blazor WebAssembly). Using it in Blazor Server Interactive might lack some features or integrations intended for its native counterpart.

Potential Migration Issues: If you rely on blazor.server.js and decide to migrate to a different hosting model or update to newer .NET versions in the future, you might encounter difficulties adapting your code due to its deprecation.

Consider alternative SignalR configurations: Depending on your specific needs, you might explore other SignalR options like using Server-Sent Events (SSE) or Long Polling with sticky sessions enabled.

Upvotes: 1

Related Questions