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.

[GrantTotinov]

I think the main reason is how the SignalR connection is structured. Each hub is mapped to its own endpoint with MapHub<T>, and the connection is associated with that endpoint. HubConnectionContext is created for the transport connection and the server uses a specific DefaultHubDispatcher for the hub.

[HubConnectionContext](https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/server/Core/src/HubConnectionContext.cs)
[HubConnectionHandler](https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/server/Core/src/HubConnectionHandler.cs)
[DefaultHubDispatcher](https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/server/Core/src/Internal/DefaultHubDispatcher.cs)

Because of that, supporting multiple hubs over the same connection would likely require changes across the connection, routing and dispatching layers, as well as the client implementations.

That said, I can definitely see the point raised about modular monoliths. Having each module own its own hub while sharing a single physical connection could be quite useful, especially when the modules are otherwise completely independent.

It would be interesting to hear if there are any architectural reasons beyond this that make a shared connection difficult, or if this is something that has been considered before.