RabbitMQ vs Socket.io?

Update

Are there scenarios I need RabbitMQ for web apps where Socket.io doesn't suffice? Browser users should be able to communicate with eachother through a node.js server. One of the user writes a message and all other users will get it.

When you only have these simple requirements then socket.io alone will be enough.. You only need a message queue when you want to process your jobs(heavy) offline and in a controlled manner.

http://en.wikipedia.org/wiki/Message_queue:

Message queues provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time.

This sentence needs to sink in. The producer (one process) puts a job into the queue and the consumer consumes by taking the job from the queue. The consumer, most times, are multiple processes that consume multiple jobs concurrently. The consumers are unable to tell from each other, what jobs they are consuming.

This makes the queue a First-In-First-Out (FIFO) data structure.

That's I think an important property of the queue. The First-In-First-Out property although with an advanced message queue like beanstalkd you can give jobs priorities.

I hope this makes any sense at all ;)

I'm doing real time live web app development.

Could you explain a little better so that we can give you a better answer?

I don't quite get how RabbitMQ works. But from quick reading it seems that it handles publication/subscription of messages.

See the quote about message queue below. Let it sink in for a while. You could also read the WIKI about message queues.

A user (in a browser) publishes something and subscribers (in other browsers) get that message. Isn't that what Socket.io is doing with websockets?

Socket.io supports a lot of different transports(also websockets) and it should because websockets are not supported by the most browsers. But for example Google Chrome does already support websockets. I believe that websockets are the transport of the future(but not yet!). When you look at Socket.io's browser support page you will notice that Socket.io does support all the major browsers(some even ancient). The nice thing is that it wraps this around a nice API.

What are the advantages/disadvantages for each one of them?

You are comparing apples to oranges so comparing that is kind of strange.

RabbitMQ

http://www.rabbitmq.com/tutorials/tutorial-one-python.html:

RabbitMQ is a message broker. The principal idea is pretty simple: it accepts and forwards messages. You can think about it as a post office: when you send mail to the post box you're pretty sure that Mr. Postman will eventually deliver the mail to your recipient. Using this metaphor RabbitMQ is a post box, a post office and a postman.

Advantages

• It is a pretty good message queue. Personally I would use redis or beanstalkd.

Disadvantages:

• Is not really for "browsers".

Socket.io

http://socket.io/:

Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms.

Advantages

• It is for browser

Disadvantages

• It is not a message queue.

Can Socket.io replace RabbitMQ?

No you can't because they are two completely different things. You are comparing apples to oranges. You should try to comprehend both descriptions from the sites I quoted.

RabbitMQ is a really flexibly way of creating network topologies. It's mature, supported, and comes from a finance space (in finance they've been doing messaging for a long long time). I use RabbitMQ server-side, and use other protocols to connect to RabbitMQ over a "gateway".

Behind the scenes, RabbitMQ is written in an ultra concise functional language called Erlang. That's no big deal in and of itself, but the contention is that if you know what you are doing, and can say it in less lines of code, then it's ultimately more reliable and testable.

btw: Erlang is used by Facebook and Twitter for their behind the scenes stuff.

Now, RabbitMQ is more than just a network sockets type thing... it's based on "guaranteed delivery". That feature is important for enterprise situations. RabbitMQ, alternatively could be used to scale... actually, there's more than that... I'm not doing it justice.

I can't comment on node.js as I haven't had a chance to play with it yet. I'm happy with RabbitMQ.

re: socket.io (are we talking websockets?) -- if this is for the browser (as the post above suggests), you could potentially bridge that into RabbitMQ. i.e. RabbitMQ is that flexible.

RabbitMQ is used as way to pass messages across applications, not necessarily users in a browser. You could then implement a RabbitMQ client in node.js for example that pushes the received messages to a browser.

See http://www.rabbitmq.com/blog/2010/11/12/rabbitmq-nodejs-rabbitjs/ for an example.