Allow DotNet SignalR to work with AWS WebSockets API

[genifycom]

My goal is to allow DotNet SignalR client and server to communicate via the AWS WebSockets API.

This would allow us to use Blazor server-side components in an AWS Lambda DotNet application.

After looking at this for some time I believe that we need a new HttpTransportType which is part LongPolling (for the incoming HTTPRequest to Lambda from AWS WebSockets API) and part WebSockets (for the immediate response back to the AWS WebSockets API).

The client will perform its normal SignalR request to AWS WebSockets API which will then forward the HTTP request to the Lambda function (with the connection id) which would route this request to the appropriate Hub and the Hub will immediately respond to the connection id with the result.

I have started to look at the Microsoft.AspNet.SignalR source code here https://github.com/SignalR/SignalR

Is anyone here more familiar with this code and could help point me to some locations to insert this new HttpTransportType?

Thanks for any assistance.

[ppittle]

If you haven't already, I'd recommend reviewing Martin Beeby's NDC Talk: Building a real-time serverless app in Blazor using AWS

[genifycom]

Thanks for that and his approach is what I have been using up to this point.

Unfortunately Beebys talk does not address SignalR or the DotNet Core support for Hubs in the serverless environment which make the server side much easier to standardize and maintain.

[genifycom]

I am guessing that I need to add the new transport to TransportManager in Microsoft.AspNet.SignalR source code here https://github.com/SignalR/SignalR

        Register("proxiedWebSockets", context => new ProxiedWebSocketTransport(context, resolver)); //TODO

[jkoplo]

Are you familiar with dotnet/aspnetcore#9522? Seems to be the same intention, though it was never quite resolved.

[brendonparker]

I had the same thought recently and found this thread/issue. Especially given the recent hotness of the Amazon.Lambda.AspNetCoreServer which abstracts away the need for a "FunctionHandler". I'm wondering if it is just putting a finger on the right extensibility point in SignalR, perhaps a new transport as @genifycom suggests like proxiedWebSockets which can take the web socket event in the lambda callback and convert it to a signalr message.

[achobanov]

I'm confused. Isn't this a question rather than a feature request? @genifycom @brendonparker any progress on this?