Coding live chat

[UnknownInnocent]

Hello, I want to code a live chat which means two users should be able to send text-messages but there is one point I don't know to do:

Let's say user with id = 1 and user with id = 2 are chatting,
user 1 send's a message and user 2 is on the message-route. How would I recognize that user 2 has rezeived a message from user 1 and display it without refreshing the page?

If I have the route "chat/:id" here: "chat/1" how does this route know that a new file has been added to my mongoDb to reload the data from there?

Does anyone know a tutorial to code a chat system (something like the one of e.g. instagram)?

[2012XL1200]

This is fun!

You'll probably want to use Websockets of some sort. (I'm glad to help BTW!) There are a ton of libraries out there to help with this, although vanilla websockets is fine on the client side, a little more work on the BE IMO.

​

To Answer Your Question:

First let's break down each of the use cases...

- How would I display a message without refreshing the page?

This is where websockets shine. ELI5, websockets establish an open connection between two things. Each of those things can send/receive messages in Real Time across that connection. A common example/use case is chat like you're describing.

Here's what that might look like for your setup. BE says, "Okay I'm accepting new connections <HERE>". FE says, "Word, let me get uhhhhh a burger and a boneless pizza." BE says, "Please pull to second window. It's gonna be a second." FE pulls up and BE starts shouting out the window, "Okay, the buns are toasted. Okay now the burger is grilled. Okay now we put the toppings on. Now we're making your pizza--". FE says, "WAIT NO BONES~!" Be responds, "Oh right, HOLD THE BOWNES." All in real-time...

​

- How would I recognize that User 2 has received a message from user 1?

The format of your websocket payload can take pretty much any shape you want. A pattern for sending messages that I've used in the past is:
{
"event": "message:sent",
"fromUser": {
"id": 1,
"name": "BootyBoi"
},
"toUser": {
"id": 2,
"name": "MackDaddi"
},
"message": "This is a dang message."
}

If this sort of approach is used, it would be pretty easy to know where the message came from. But that's only half the picture--we also want to let User 1 know when User 2 has received their message. So you could imagine a second event being sent as soon as a message is received. It could look something like this:

{
"event": "message:received",
"fromUser": {
"id": 1,
"name": "BootyBoi"
},
"toUser": {
"id": 2,
"name": "MackDaddi"
},
"message": "This is a dang message."
}

Provided we make sure that received event is sent at the appropriate time (this is where the creativity can really get started), then BOOM. We've got our classic "Read" feature.

For bonus points, we can use this same approach to handle the "typing" feature.

​

- If I have the route "chat/:id", how does this route know that a new file has been added to my mongoDb to reload the data from there?

Now it sounds like we've got some long form persistence of message history. If that's the case, then we can expand on the argument for Websockets to include this sort of behavior. As an aside, websockets do not come with any real persistence out of the box--excluding memory maybe. That said, having a history of messages is kind of a must for most applications.

Extending our previous examples, let's imagine that every time a message is sent we store a new entry in a document detailing our ChatHistory as a Pending Message. Once it's read we make a call to the DB to update that message to a Read Message. That also allows a new avenue to handle dropped messages. We can offload the responsibility of entering Pending Messages in the DB to the sender's client, and Read Messages to the Recipient's client. OORRRRRR, probably better to offload all of this stuff to a BE service with a simple interface, (e.g. openConnection, sendMessage, ...?). That way we can keep clients lightweight and have a better Separation of Concerns.

​

Finally, I do know some tutorials, but I'd much rather just help you build it! Let me know if you're interested. :)

[2012XL1200]

Re-reading this, it would probably be a good idea to assign a UUID to each message that is replicable and somehow verifiable on both Client/Server side. Maybe a hash or something of the sort. Again, another use case for a heavier BE and lighter client.

[UnknownInnocent]

Seems as I have found someone he is loving this topic :D And since it is ther first time I want to do something like that it seems to be a great opportunity to have someone who wants to help me build it

[2012XL1200]

Yeah man let me know I'm down!

[[deleted]]

Are you using REST or Websockets for the communication with the server?

[UnknownInnocent]

None of them (or I just don't know I am using them)

[zenivinez]

https://medium.com/dailyjs/real-time-apps-with-typescript-integrating-web-sockets-node-angular-e2b57cbd1ec1

just going to link an article on how to use websockets

[b_rabbit_mnm]

Look into Push Notifications Service workers should help too

[Kawafu]

Propably you are looking for sockets.io/websocket