Odonno
commented
3 years ago @m-sterspace Well, there's some news about this recently (really). It seems there is now a serverless service called Azure Web PubSub which is built on top of websockets. I don't really know how it works but I suppose it is something you can start looking at: https://azure.microsoft.com/en-us/blog/easily-build-realtime-apps-with-websockets-and-azure-web-pubsub-now-in-preview/
About SignalR, you're right, it is only for .NET ecosystem (server-side) but you can use it in JS if you want on the client since it is language agnostic on the client-side. If you'd want something in nodejs, I suppose you can opt in for socket.io or any other alternative in the market right now.
zrml
We've received feedback from customers that Azure Functions should support WebSockets to enable realtime scenarios. See here for some discussion: https://github.com/Azure/azure-functions-host/issues/1139
There are some challenges here because WebSocket is really a stateful protocol (you have a long lived connection between a given client and a given server) while Azure Functions is designed to be stateless. For example, we will often deprovision a Function App from one VM and start it on a different VM (perhaps in a different scale unit) based on capacity constraints. This is safe to do for us today because of our stateless design - but if we did it when there were WebSockets connections to that VM, we'd be terminating those connections.
There are also open questions from a billing perspective. Today the consumption plan for Azure Functions bills per execution, but if a WebSocket server is listening on an idle connection, this consumes resources but where are the "executions"?
In summary, there are open issues around design, billing, and technical implementation. I think there are reasonable solutions to these issues and we just need to start working on them once this feature is high enough on our list of priorities.