Why do you need a message queue for a chat with web sockets?
Asked Answered
K

4

17

I have seen a lot of examples on the internet of chats using web sockets and RabbitMQ (https://github.com/videlalvaro/rabbitmq-chat), however I do not understand why it is need it a message queue for a chat application.

Why it is not ok to send the message from the browser via web sockets to the server and then the server to broadcast that message to the rest of active browsers using again web sockets with broadcast method? (maybe I am missing something)

Pseudo code examples (using socket.io):

// client (browser)
socket.emit("message","my great message that will be received by all"


// server (any server can be, but let's just say that it is also written in JavaScript
socket.on("message", function(msg) {
  socket.broadcast.emit(data);
});

// the rest of the browsers
socket.on("message", function(msg) {
  // display on the screen the message 
});
Kaph answered 24/8, 2016 at 11:36 Comment(0)
E
15

i don't think RabbitMQ should be used for a chat room, personally. at least, not in the "chat" or "room" part of the application.

unless your chat rooms don't care about history at all - and i think most do care about that - a message queue like RMQ doesn't make much sense.

you would be better off storing the message in a database and keeping a marker for each user to say what message they last saw.

now, you may end up needing something like RMQ to facilitate the process of the chat application. you can offload process from the web servers, for example, and push all messages through RMQ to a back-end service that updates the database and cache layers, for example.

this would allow you to scale the front-end web servers much faster, and support more users per web server. and that sounds like a good use of RMQ, but is not specific to chat apps. it's just good practice for scaling web apps / systems.

the key, in my experience, is that RMQ is not responsible for delivery of the messages to the users / chat rooms. that happens through websockets or similar technologies that are designed to be used per user.

Engineer answered 24/8, 2016 at 13:55 Comment(1)
basically RabbitMQ helps in a real time application due to the fact that the main server which received the request can send it to the RMQ and then RMQ can send it to multiple parties. And the optimization is the fact that the main server is going to do just one request to RMQ and then is free to accept other clients. (in this way he is not responsible with updating all the parties) Is this correct?Kaph
J
7

Simple answer ...

For a simple chat app you don't need a queue (e.g. signalr would do exactly this without the queue).

Typically though real world applications are not just "a simple chat app", the queue might represent the current state of the room for new users joining perhaps, so the server knows what list of messages to serve up when that happens.

Also it's worth noting that message queues are often implemented when you want reliable messaging (e.g. Service bus) to ensure that all messages definitely get to where they should go even if the first attempt fails. So it's likely that the queue is included in many examples as a default primer in to later problem solving.

Jackleg answered 24/8, 2016 at 13:5 Comment(0)
T
4

I may be late for the answer as the messaging domain changed rapidly in last few years. Applications like WhatsApp do not store messages in their database, and also provide E2E encryption. Coming to RabbitMQ, they support MQTT protocol which is ideal for low latency high scalability applications. Thus using such queuing services offload the heavy work from your server and provide features like scalability and security.

Telephonist answered 21/3, 2021 at 11:45 Comment(0)
F
0

uhmm I didn't understand exactly for are you looking for...

but In RabbiMQ you always publish a messages to an exchange and consume the message using a queue.

to "broadcast that message" you need to consume it.

hope it helps

Furthermore answered 24/8, 2016 at 12:53 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.