7 ms·
I would advise against Blazor Server. In contrast to standard frontend SPA frameworks, Blazor Server requires a peristent websocket connection to each client
by platz 4y ago
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
- lovetocode 4y agoIt 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?
- useerup 4y ago> 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 4y agoEspecially on backgrounded browser tabs, users circuts were frequently lost. also People frequently multitask their activities. 3 minutes is nothing.