3 ms·

Hey, how is this diff from a simple WebSockets implementation?

• tuukkah 9y ago
  Or MQTT over WebSockets?
  • jkarneges 9y ago
    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.
• jkarneges 9y 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.
  • Xeoncross 9y ago
    Socket.io also proxies websocket events as HTTP if needed. So is this is basically socket.io as a service?
    • jkarneges 9y ago
      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).
    • kondro 9y ago
      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.