Aspnetcore: Consider a "standalone" SignalR backplane solution

[davidfowl]

We can start with a basic implementation that is a standalone application that needs to be hosted in order to function, no fancy clustering just yet. Everyone connects to the SignalR backplane service and we treat it like a remote cache.

One downside of doing it this way is that the backplane service would need to be scaled out as well...

[grahamehorner]

I’m looking into something similar, with #ServiceFabric hub-spoke configurations and mesh, also looking at the possibility of a #ServiceFabric in memory #EF provider

[KPixel]

Is this similar to the idea I discussed here #684, replacing Redis with SignalR itself?

[davidfowl]

@KPixel basically, there are questions on how to scale out the signalr used for messaging though.

[anurse]

Retargetting this to focus on an on-premise "standalone" backplane, primarily for cases where Redis and Azure SignalR is infeasible (i.e. On-Premise Windows).

[legistek]

Wondering if there's anything new on this since August? Is there any way to use SignalR with a load balancer other than Redis caching right now? I would like a solution that doesn't require any additional infrastructure beyond IIS and maybe SQL Server.

FWIW having no replacement for SQL backplaning is the only thing blocking me from updating to ASP.NET Core from Framework.

[anurse]

There are no new plans right now, but your feedback is noted! This thread is where we'd discuss any new plans.

We are looking at planning for 5.0 and while I can't make any promises, it's good to know you have interest in this and that it's blocking migration for you. We'll consider that in our planning process.

[leonkosak]

I would also prefer SQL backplane for not so intensive cluster environments - SQL Server and Postgres.

[szalapski]

I would like to see this, especially if it is much simpler than spinning up a redis instance.

[mezzo1981]

Any news on this topic for supporting a simple Backplane or bring back the SQL Backplane?