Hey, how is this diff from a simple WebSockets implementation?
1) Fanout can proxy WebSocket client events as as series of HTTP requests to the origin server. This means you can use a normal web backend or FaaS to manage the connections, which is even simpler than having to write a custom stateful server process.
2) Connections are delegated to Fanout, and we handle 1-to-many propagation, for high scalability.
So is this is basically socket.io as a service?
Edit: or, are you talking about HTTP fallback on the client side, when WebSockets aren't available? Fanout can do that too, but what I was talking about earlier was how Fanout can speak WebSockets to the client and HTTP to the server (like an inverted sockjs/engine.io).
So it's not that the two are incompatible options necessarily, but that you could use Fanout to scale out such an implementation.