Why core SignalR doesn't support multiple hubs per connection

[achobanov]

I've been using SignalR in a local network environment for integrated apps and I have several situations where multiple concurrent SignalR connections are established, because I have segregated my hubs in a similar fashion as I would API controllers.

My question arose out of some implementation difficulties on the clients with maintaining multiple connections. Mainly I am using events to render changes in connection status. However I don't need a separate indication for every connection - I only have one, because I am connecting to a single server. So if a connection closes, I simultaneously report it from multiple clients and also simultaneously start concurrent processes to attempt to re-establish a connection.

From a high-level engineering standpoint I am thinking I will be better off if I have a single connection instance with one big hub and multiple clients reusing it. But what about lower level?

And so I arrive at my question. It seems to me that if the team prevented multiple hubs with one connection instance, as it was previously possible in .Net Framework - there should be a reason behind it. What is it?

[ricoprzybylski]

+1 Same boat here, and I want to add the modular monolith angle because I think it makes the case stronger than just "I have a lot of hubs".

Our app is a modular monolith. Each module is its own project (some are NuGet packages) with its own domain, its own DI registrations, its own controllers and minimal API endpoints. The host project just wires them up and knows almost nothing about their internals. That works fine for everything... except real-time. A module can ship its own controllers, but it can't really ship its own hub, because a connection in ASP.NET Core SignalR is bound to exactly one hub.