Is it possible to implement istyping status in messaging without interaction with database.
Urgent help needed?
I’ve not implemented this feature so I haven’t put much thought into it.
But I’d recommend checking the socialize package by @copleykj which has isTyping implemented.
I personally would start with the DB then optimize to move it to in-memory only because of Meteor’s pub/sub makes prototyping easier. In the long run, I think it make sense to have in-memory in order to decrease latency and I don’t think we need to have long-term memory (DB collection) of who was typing and when, so I don’t see a use of the DB aside from Meteor pub/sub.
2 Likes
All of the socialize packages also implement redis-oplog when it’s available and the who’s typing feature of socialize:messaging uses redis-oplog’s synthetic mutator to bypass the database altogether.
4 Likes
I have used 2 approaches:
- There is a package from RocketChat called streamer (if I remember the name well) that allows to send a message through a channel and then subscribe other peers to listen that message.
- Use a third party free service (at least free until you met some limit) like PubNub (1 million free messages a month) that simplifies the code and do not imply your server.
I would choose option 2 and see how it goes.
You should also be aware of implement some throttle/debounce for the event and have the client side data as a reactive source so re renders occur when needed
1 Like
@jmaguirrei
Thanks for your input.
Should i use PubNub for whole chat application or just small things like isTyping,read/unread(message read by user or not)
If you are persisting messages, just write them to Mongo and then every peer will see it.
Use streams only for volatile data, like typing indicator because you will not be persisting it
1 Like