Hacker News new | ask | show | jobs
by jkarneges 3190 days ago
A couple of main differences:

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.

1 comments

Socket.io also proxies websocket events as HTTP if needed.

So is this is basically socket.io as a service?

Interesting! Do you have a link to any info about this?

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).

No, the bit that is different about Fanout is that the HTTP servers don’t need to necessarily know about the fact they’re coming from a persistent connection. The backend servers remain as stateless HTTP servers.