Super happy to ship Azure Web Pub Sub! A new azure service for doing pure websockets + HTTP triggering!
https://azure.microsoft.com/en-us/blog/easily-build-realtime-apps-with-websockets-and-azure-web-pubsub-now-in-preview/ #azure #websockets

How is it different from SignalR you ask? Well internally it's built on the same underlying tech but the big difference is that there's no client requirement or protocol requirement, BYOWL (bring your own websocket library).

The mainline scenarios are also focused on severless so we can handle your long running websocket connections and trigger HTTP calls to any backend. It can be azure functions or any addressable HTTP endpoint!

And no, Azure SignalR isn't dead, it's alive and kicking for all of your #signalr needs :).

Unlike SignalR, Azure Web Pubsub is just websockets, there's no long polling or server sent events fallback nor automatic reconnect, it's just you an your websocket client.

This lowers the barrier of entry for using the service, you just need an HTTP client and a websocket client to get going.

And lastly, if you're using Azure SignalR continue to do so unless there's something limiting you from using it in more places. This service won't benefit you if that's not the case.

Here are some samples in lots of different languages https://azure.github.io/azure-webpubsub/ #javascript #python #dotnet #java

Here are some reasons to stick with Azure SignalR:
- Your primarily a .NET shop
- If you need fallback transports other than WebSockets (Long polling, Server sent events).
- The existing SignalR client platforms work for you (including 3rd party swift and python clients).

- You need more complex invocation patterns and you don't want to manage a custom protocol. SignalR supports RPC, Streaming etc.
- Handling connectivity/keep alive/pings. The SignalR protocol makes sure that connections stay alive by sending pings back and forth.

- If you need a low latency end to end connection between your application code and the service. Azure Web pubsub currently only supports serverless backends (HTTP based), this wouldn't be as great for things like gaming (though I know we're not all writing games).

- If you don't want to manage the reconnect logic yourself.

Azure Web Pubsub gets you more reach (raw websockets) at the cost of putting more of the logic in your hands. This works well if you have simple application messaging patterns.