[platz]

I would advise against Blazor Server. In contrast to standard frontend SPA frameworks, Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state. I found that connection is easily/fequently disrupted resulting in an app reset, lost state, and poor user experience, to say nothing of the scalability implications.

Though, for a purely back-office app with minimal state, that might be OK

[useerup]

> Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state

Blazor Server retains the circuit for up to 3 minutes if the connection is lost, so you do not loose the connection even if the websocket connection is interrupted.

It is also not correct that it needs a websocket connection. It builds on SignalR which will use websockets if available but will fall back to other methods such as long polling to emulate a persistent connection.

Blazor Server absolutely has it's place, but you need to know when that is. You can even scale it out on multiple servers, but at least until .NET 7 you'll need to ensure "sticky" connections (the client must connect to the same server based on e.g. IP address, cookie or similar).

[platz]

Especially on backgrounded browser tabs, users circuts were frequently lost. also People frequently multitask their activities. 3 minutes is nothing.

[lovetocode]

It sounds like you have been using Blazor a lot more than I have so I’ll take your word for it. I haven’t any massive traffic yet. Is this something I can reproduce with a benchmarking tool?