CODEWITHSUNDEEP
node.jssocket.iochat
Ryan Murphy
Ryan Murphy

Reputation: 163

Mobile Chat application on Google App Engine and Socket.IO

I am creating a chat application with Node.js's Socket.IO and there are a couple of things I need clarification on.

I am implementing offline messaging in my app meaning that when a user opens the app he will receive all the messages he missed when they were online.

This is my approach:

  1. The client opens the app and is subscribed or joins a room.
  2. The client sends a message to Socket.IO.
  3. Socket.IO inserts the message in some kind of database/datastore.
  4. When the client tries to retrieve the messages it is pulled from the database/datastore and saved on the user's phone, then it is deleted from the database.

Is this a correct approach?

I was looking online and some people suggested using task/message queues like Google App Engines Task Queue, but I am not sure how this works.

Upvotes: 1

Views: 223

Answers (1)

nadavvadan
nadavvadan

Reputation: 4190

Your approach sounds OK, but I wouldn't delete messages from a DB, at least not immediately after the client receives them.

From your question it seems that you're not currently saving the messages to a database. This approach has some drawbacks; for example, the user can't view their chat history on a device that was not connected when some of the messages were sent.

There are 2 ways I can think of to do it in a more elegant manner:

  1. Save all messages to DB. on websocket connection and reconnections, fetch all messages newer than your latest message (This approach assumes no edit functionality in your chat, as edits will not be fetched this way). The latter can be implemented using either HTTP or WebSockets.
  2. If you don't want to store the messages in your server, then you should implement some sort of persistent cache in the device used to send the messages. This is very similar to your original solution, except that instead of storing the messages in a database, you're storing them on the user's device. this does require some logic to detect when messages are received, and when the recipient reconnects, in order to trigger sending the missing messages.

The first approach is much better for the general use case in my opinion, but it depends on your use case.

Upvotes: 1

Related Questions