[whoknowsidont]

Don't. Unless you're a client-side web tech expert, Blazor will break under production load.

Things will work fine in QA, but it's not a robust framework. So when things break, they break hard, leaving your end-users in the ditch.

Something like Phoenix LiveView is a much better option.

[debacle]

Is it using something like websockets to stream data?

[whoknowsidont]

Yes, it can, and by default be through SignalR. The problem is both SignalR has its own limitations as well as web-sockets in general.

I have never seen a SignalR (and recently Blazor) implementation without significant and characteristic issues the moment you actually star to observe end-user errors/issue/anatomies. Either through automated reporting or user feedback. And this is because SignalR is built on .NET and .NET has many different threading issues when you need those thread to be stable and robust (not talking about transit B2B apps)

It always happens. Without exception.

You do not have to take my word for it, look at the active, open, and historical issues here: https://github.com/SignalR/SignalR/issues

The issues are plainly fundamental.

It's absurd. And it only survives because it's Microsoft.

[sebazzz]

That version of SignalR you are referring to is from .NET framework and really bolted on. That version of the framework had async/await in ASP.NET also bolted on, and the threads itself use a synchronisation context and locks.

This is mostly no longer the case in modern .NET. SignalR is a core part of the framework and completely rewritten.

In our case, Blazor Server has been very stable for us, also for multiple users.