Reactivity and model for simple chat feature

Hello All,

We want to build a simple chat feature in our application.

we thought of a model like this,

{
  postId: 'link to post where we have users details',
  messages: [
    {
      from: 'userId',
      to: 'userId',
      sentAt: new Date()
    },
    {
      from: 'userId',
      to: 'userId',
      sentAt: new Date()
    },
    {
      from: 'userId',
      to: 'userId',
      sentAt: new Date()
    },
    .
    .
    .

  ]
}

and we will subscibe to the collection on client side based on postId

if there is any new messages we will push it to messages property.

Our worry here is,

as meteor can only identify the changes on root properties, whenever we insert a new message we worried that meteor will send back all the messages object again to client side.

So we’re wasting bandwidth.

Can somebody confirm that meteor can only observe changes on root properties.

because of the above issue we thought of some other model, which is simply saving each message as new record

{ from: 'userId',to: 'userId',postId:'',sentAt: new Date(), msg: '' }
{ from: 'userId',to: 'userId',postId:'',sentAt: new Date(), msg: '' }
{ from: 'userId',to: 'userId',postId:'',sentAt: new Date(), msg: '' }
{ from: 'userId',to: 'userId',postId:'',sentAt: new Date(), msg: '' }

but we worry that there will be too many number of records we’re saving in collection.

We know lot of meteor developers have developed chat application before, we just want to know their thoughts on this and what worked very well for them.

Thanks

Hi, welcome to the Meteor forums!

Completely ignoring the observe changes on root properties for a moment, the first approach will not scale, remember a Mongo document can only be 16MB. So right off the bat, you have a hard limit of how many times a person can reply.

Extract the messages as it’s own collection, and link them to the users - as shown in your second approach.

1 Like

Thank you for response,

Ours is not a messenging platform, chat is just a small feature of our app. We don’t think we will reach 16mb limit ( we only use text, no base64 and others heavy data) in any time.

Is there any limitations if we use second approach and can you tell us something about observing changes on root properties?

The first approach won’t scale well with meteor for the reasons you’ve mentioned yourself.
Everytime a message is added, the entire message array will be send over the client. The second approach has no real limitations

Like that you can also page the messages (real paging or infinite scroll), the first approach would require you to send all the messages or slice them, but if you use slice, meteor can’t use oplog tailing for that query.

1 Like

@sasikanth you have youtube videos about chat app !!!

Actually I implemented my first chat feature using that so Thanks man !!

Have you checked out https://github.com/copleykj/socialize-messaging ??

It has all the bells and whistles necessary for a chat app. Including writing.. and all that

package looks great will look into the code. Thanks.

1 Like