Server-side Blazor: Consistently push to multiple circuits

[Trolldemorted]

Is your feature request related to a problem? Please describe.

There are several issues that ask about how we should push data to clients (e.g. #10559, #14778), and none has received a clear response so far.

The absence of documentation and guidance has fostered blogs and demos that propose odd workarounds, such as opening a new, dedicated signalr connection to a dedicated hub from within the circuit or making circuits subscribe and unsubscribe to a public static delegate while praying that everything is correctly disposed.

If I understand @rynowak correctly we could set up a ConcurrentQueue per circuit, have $something fill it, have a background thread drain it, and invoke StateHasChanged. However we are lacking concise instructions on thread safety in server-side blazor (should we update the "model" from the background thread and then just invoke? Does the circuit's "main task" have a synchronization context? Should we pass updated models to the circuit in a special way?), so this is not something I can use to build an app with.

Describe the solution you'd like

The documentation should present a bulletproof scheme that allows us to easily dispatch an event to sets of circuits!

We have to be sure that

• we are not violating any thread-safety assumptions (Winforms/WPF/UWP don't allow to modify UI components without invoking the UI thread, and I could not find any documentation for server-side blazor)
• no resources are leaked (if clients disconnect, connections are aborted, ...)
• no scaling issues arise for small to medium user bases
• ordering (every user agent sees event A before event B) can be enforced
• we can handle overload situations gracefully (we want to be able to check whether A is done before we start B, because if C comes in before A is done we might want to skip B)

I am fairly certain that right now everyone developing a server-side blazor app which provides inter-circuit communication is reinventing the same wheel, and this wheel is at a crucial position in everyone's webapp, and that is awful, because most of those (including me) won't have the required internal knowledge to know the lifecycles and pitfalls of server-side blazor.

If the response is "we won't support that ourselves within the near future, please use a dedicated message broker like redis/whateverMQ" that is completely fine (and reasonable for scale out scenarios), but please provide a reliable minimal example that interested parties can use to build a prototype.

[pranavkm]

Thanks for your issue report. We'll look at getting some samples or guidance added to cover this scenario.

[schmitch]

I mean I think most people probably wan't to stream data to multiple clients, which triggers a rerender without going trough
server -> client (javascript signalr or so) -> calls blazor callable js function (which involves a server roundtrip) -> re-render.

I think most people just want something like a IAsyncEnumerable<Data> that multiple "users/circuits" can subscribe to, without going trough the server -> client -> server hop.

[mkArtakMSFT]

We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.