better blazor scale-out documentation

[schmitch]

currently our company want's to scale-out blazor a little bit, however the documentation is really lacking, especially what happens if redis/azure signalr services is used as a backend.

I mean currently SignalR itself can be configured without sticky sessions and redis.
However there is nearly no documentation, if something like that can be done with blazor.

Also what happens in case of a server failure, can a secon server take over the work when signalr runs with a redis backing store? or does blazor still keep everything in memory?

[pranavkm]

@schmitch there's a fair bit of documentation about deploying Blazor with Azure SignalR Service here: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/blazor/server?view=aspnetcore-3.1#signalr-configuration which states that sticky sessions are required. https://docs.microsoft.com/en-us/aspnet/core/blazor/state-management?view=aspnetcore-3.1 also covers some details about how to effectively manage state with multiservers.

Do these documents cover your questions?

[nullpainter]

I'm in the same boat as @schmitch. I have read that sticky sessions are not required when using Redis and if the only transport is WebSockets, but this appears to require client-side configuration. I can't see any documentation about whether this is possible to configure with Blazor.

I've implemented custom state management for ephemeral state, but this isn't really the issue.

What I'm looking for is a practical guide on how to redeploy or upgrade nodes in a multi-node cluster without the "Could not reconnect to the server. Reload the page to restore functionality." error being displayed to end users.

I was assuming - perhaps naively, having not played with SignalR before - that I could use a Redis backplane, somehow disable the need for sticky sessions, and all state is replicated across servers.

I modified ConfigureServices to add Redis support to SignalR:

services.AddServerSideBlazor();
services.AddSignalR().AddStackExchangeRedis(...);

I can see pub/sub channels created, but I can't see any messages being sent. Should there be?

tl;dr - how is one supposed to scale out Blazor applications, not use Azure SignalR Service, and maintain zero-downtime for end users? The state management page is only part of the puzzle, and that seems a fairly straightforward one to address.

[nullpainter]

This is a similar question to #9734, with the same state management page discussed, however this doesn't address that poster's concerns either.

It's straightforward to persist application state (view models etc.) via an ad-hoc state manager, but what is resulting in the 'could not reconnect' message? Is there some way to implement a non ad-hoc manager - i.e. some sort of state manager registered with Blazor - so Blazor automatically reconnects?

I assumed this message was relating to the SignalR connection being broken, so I'm confused why the state management page keeps being referenced.

[nullpainter]

Or is the message that SignalR terminations are unavoidable, and that the Blazor approach is for the developer to to maintain state as per ASP.NET Core Blazor state management?

[physix99]

I also have come across the same issue. It's impossible to update a blazor server side app without all connected clients receiving the connection disconnected message - which I understand why, but I'd really like a workaround.

The same thing also happens when you use Azure Deployment slots and using Azure SignalR service, as ultimately the signalr circuit is being lost.

Your idea of using Redis for the signalr connections would have been great if that worked. Is it possible for that to be implemented?

@danroth27 can the client circuit object be serialized?

[danroth27]

@physix99 There are a number of different ways you can handle persisting the app state for a given client: https://docs.microsoft.com/aspnet/core/blazor/state-management?pivots=server In .NET 5, the support for using protected browser storage will be built in to the framework.

[physix99]

@danroth27 Thanks Dan for your reply.

What I was actually referring to was serializing the signalr client object for Blazor Server. Which is what i believe contains all the information about the client (e.g. information needed to render the DOM).

What i'm after is being able to have 2 back end blazor servers for load balancing. Azure Signalr service in front of them - sticky sessions turned off.

Then if we need to update the blazor server application, we can do 1 server. All the signalr connections to that server will be dropped, but Azure will automatically join them to the other server. Because the Blazor Server circuit has been serialised between the two (using whatever mechanism needed), the client will join to the remaining online server with a very minimal reconnecting screen.

Obviously if there has been big changes the client will need to refresh the page to remake the connection, but for all major changes it should be good enough?

Thanks