Users create demands, and providers offer a proposition to it.
On the front, it opens a conversation between the user and the provider in the messaging tab:
User’s POV
User’s POV
Provider’s POV
Provider’s POV
The two users CAN NOT talk before the user accepts or refuses the demand. Then, it establishes on the back-end a WebSocket connection to the messaging API to send messages or receive messages in real-time.
notion image
Sender emits sendMessage to the WebSocket server, whose dispatch the receiveMessage to the receiver and back to the sender. It also saves it in the messages collection of the Mongo database.

Technical explanations


GET /api/chat/:userId
userID in params correspond to the user to who you’re talking.
OUTPUT: Returns the conversation messages sorted by their creation date in an array.
GET /api/chat/last
Only requires the user’s token in the Authorization Bearer.
OUTPUT: Returns an array with the last messages sent or received with anyone.
GET /api/chat/unread
Only requires the user’s token in the Authorization Bearer. .
OUTPUT: Returns all the user’s unread messages.
POST /api/chat/read
Requires the user’s token in the Authorization Bearer, and the target Id in the body.
OUTPUT: Read messages received from the specified user.


On connection to the WebSocket server, send your user’s token in the header like the fo:

To send messages, as saied above, emit to sendMessage event the following content:
{ "receiverId": "<user's ID here>", "message": "<message content>" }
And, listen for any received messages with the receiveMessage event.

Upcoming changes

As you can see, in some routes I sometimes ask for the target ID as a header, sometimes as a parameter or even your token instead of getting it from the Bearer. These are errors that I will correct later.
© All rights reserved🌸 Carbon neutral, or maybe not.by suiramdev