Faye vs. Socket.IO (and Juggernaut)

Solution 1:

Disclosure: I am the author of Faye.

1. Regarding Faye, everything you've said is true.
2. Faye implements most of Bayeux, the only thing missing right now is service channels, which I've yet to be convinced of the usefulness of. In particular Faye is designed to be compatible with the CometD reference implementation of Bayeux, which has a large bearing on the following.
3. Conceptually, yes: Faye could use Socket.IO. In practise, there are some barriers to this:
   • I've no idea what kind of server-side support Socket.IO requires, and the requirement that the Faye client (there are server-side clients in Node and Ruby, remember) be able to talk to any Bayeux server (and the Faye server to any Bayeux client) may be deal-breaker.
   • Bayeux has specific requirements that servers and clients support certain transport types, and says how to negotiate which one to use. It also specifies how they are used, for example how the Content-Type of an XHR request affects how its content is interpreted.
   • For some types of error handling I need direct access to the transport, for example resending messages when a client reconnects after a Node WebSocket dies.
   • Please correct me if I've got any of this wrong - this is based on a cursory scan of the Socket.IO documentation.
4. Faye is just pub/sub, it's just based on a slightly more complex protocol and has a lot of niceties built in:
   • Server- and client-side extensions
   • Wildcard pattern-matching on channel routes
   • Automatic reconnection, e.g. when WebSockets die or the server goes offline
   • The client works in all browsers, on phones, and server-side on Node and Ruby

Faye probably looks a lot more complex compared to Juggernaut because Juggernaut delegates more, e.g. it delegates transport negotiation to Socket.IO and message routing to Redis. These are both fine decisions, but my decision to use Bayeux means I have to do more work myself.

As for design philosophy, Faye's overriding goal is that it should work everywhere the Web is available and should be absolutely trivial to get going with. I'ts really simple to get started with but its extensibility means it can be customized in quite powerful ways, for example you can turn it into a server-to-client push service (i.e. stop arbitrary clients pushing to it) by adding authentication extensions.

There is also work underway to make it more flexible on the server side. I'm looking at adding clustering support, and making the core pub-sub engine pluggable so you could use Faye as a stateless web frontend for another pub-sub system like Redis or AMQP.

I hope this has been helpful.

Solution 2:

1. AFAIK, yes, apart from the fact Juggernaut only uses Redis for Pubsub, not persistence. Also means client libraries in most languages have already been written (since it just needs a Redis adapter).
2. Juggernaut doesn't implement Bayeux, but rather has a very simple custom JSON protocol
3. I don't know, but probably
4. Juggernaut is very simple, and designed to be that way. Although I haven't used Faye, from the docs it looks like it has a lot more features than just PubSub. Being built on top of Socket.IO has it advantages too, Juggernaut's supported in practically every browser, both desktop and mobile.

I'll be really interested in what Faye's author has to say. As I say, I haven't used it and it would be great to know how it compares to Juggernaut. It's probably the case of using the best tool for the job. If it's pubsub you need, Juggernaut does that very well.