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.
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.
Although we have not actually tested this, it should be possible for applications to make Fanout speak the MQTT over WebSockets protocol (and if this is not possible then I'd consider it a bug).
So it's not that the two are incompatible options necessarily, but that you could use Fanout to scale out such an 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.