signalr different "backends" for different hubs

[schmitch]

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

with the rise of blazor server side it would be a good idea to also have the ability to configure different "backends" for signalr. i.e. consider the following: ChatHub -> Redis Blazor Memory (Stick Sessions)

thus it would make scaling a little bit easier, especially combining the two.

Describe the solution you'd like

probably have something like: AddSignalR("Chat").AddStackExchangeRedis() and than: app.MapHub<DemoHub>("/Chart", options => {}, "Chat");

of course syntax can be different.

Edit:

maybe as an information, this is basically already possible "somewhat", but it's probably not known that much via:

.AddSingleton(typeof(HubLifetimeManager<HubClass>), typeof(RedisHubLifetimeManager<HubClass>)

of course this probably makes the syntax like: AddSignalR("Chat").AddHubBackend<HubClass>(options => options.UseStackExchangeRedis())) probably a good idea

[davidfowl]

Seems reasonable. Something like AddRedis<THub> (and an overload for adding the default impl per hub) Like all of our other APIs, it should be based on the hub type. The other thing to consider is the RedisOptions might need to have a generic version as a result so you can configure these per hub.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[halter73]

FWIW, @BrennanConroy was discussing this in triage and does not think .AddStackExchangeRedis() should affect server-side Blazor connections. Those should always use the default in-memory HubLifetimeManager.

[boreys]

This sounds like Blazor app cannot be scaled horizontally because of this in-memory HubLifetimeManager