We are displaying list of messages on user message feed. Messages are stored in a feed collection, where its organized by users. We want want track if user has seen the message or not
feed/{user_id}/
{message_id1: {seen:0,score:0.2}}
{message_id2: {seen:0,score:0.2}}
{message_id3: {seen:1,score:0.2}}
At present we are thinking to update "seen" boolean for a given message if user has seen it. Are there more efficient ways to do this in firebase (e.g. firebase native analytics). Not sure if doing so many writes back efficient
There are two common ways to track what messages a user has seen:
Keep a flag for each message that the user has seen.
Keep the timestamp/key of the most recent message that the user has seen.
The letter is a lot easier to implement, but relies in the fact users typically read message in order: scrolling from their oldest unread message to the newest message. If that is not the case for you, there's not really a better option than tracking the status for each message (and in a multi-user chat room, for each user too).
Also see:
How to structure NoSQL messages to get unreads by 1 query? (long explanation with examples of the same use-case, but then for Firebase's Realtime Database)
Related
I keep going back and forth about choosing DynamoDB or RDS for my project. I understand they are 2 completely different kinds of DB systems, but I am not sure which one would be a better fit for my app. My app alerts users of certain events that happen VERY infrequently.
For instance, an employee may trigger an alert saying that there is an active shooter in the building, so my app needs to get the cell phone numbers of everyone in the company from the database and then use those numbers to send text messages. I just discovered that DynamoDB has a limit of 100 items when retrieving stuff from the database, which is a problem for me because I may have to retrieve 200 or 300 or even more phone numbers as quickly as possible.
In addition to this, the database would not be queried regularly. It would be queried rarely when someone needs to update a user's profile information. of course, it would be queried for users' cell phone numbers in an emergency and I need this to return the results as fast as possible.
It kind of sounds like DynamoDB may be an overkill, but I am not 100 % sure. On the other hand, It seems a PERFECT fit since it can query stuff really quickly, but the limit of 100 items per request just kills me.
To me, there isn't a clear answer in terms of what database system to choose. Based on this use case, what is the best DB option?
You should use AWS pinpoint for that. Pinpoint has endpoints and segments.
The endpoint is email, number... One person in the company can have multiple endpoints.
The segment is a filtered list of endpoints. For example, you can filter endpoints by person title, or by company.
You create Campaign based on segments, so each person in selected segments get email or SMS or both...
Regarding your example, you can create a dynamo DB trigger which will create/update/delete pinpoint endpoints.
AWS approach is not to scan dynamo DB to send group emails or SMS. Instead of that, the approach is to create segment and then create campaigns.
When building a chat app with React Native and Redux, with Firestore for backend, what is the best way to load messages for a particular conversation?
I display 8 chat entries in the beginning, and when I click at one I will see the chat screen with 20 latest messages. Is it a good idea to implement real time listeners to each chat's (not all chats, just those that are displayed, because pagination is used) 20 latest messages from each one's messages collection and have them ready beforehand?
Or is it a better idea to load the messages when a particular chat's messages screen is being opened.
I understand that as user experience the first option is better because there is no latency in showing the first 20 messages for a chat, but doesn't it consume a lot of data that might never be necessary, because out of the 8 chats, the user might interact with only 2 or 3.
Is there any better way besides these two?
Thanks in advance!
If is a good idea or not, it's up to you to decide according to what kind of chat app you want to create. It's always a trade between the latency that you were talking about and the amount of data that you get and that might be or might not be seen by the user. Furthermore, if you say you have 8 chat rooms with 20 messages, it means that by default, when the user opens your chat app, Firestore will charge you with 8*20=160 read operations, even if the user enters a chat room or not and I think is not such a good idea. If you have a few users, there won't be a problem but if your app grows, you might think again about this. In Firestore, everything is about the number of reads and writes according to their pricing plan.
In my opinion, you should think of upgrading your UX by giving the app offline capabilities instead of loading unnecessary data all at one. You should fetch data for a concerned chat and make your app memorize the latest 10-20 messages and you can always sync your data. You might want to consider Realm or SQLite.
Also for better UX for the chats screen where the chats will be shown, you should consider making your chat-list node to accomodate last message and timestamp in each chat so that you wont have to nest the query for each chat item for just one screen rendering.
I want to track the number of unseen messages for each member of a group chat. I store chat metadata in a chats collection, and messages for each chat in messages/{chatId}.
I have checked other threads that ask about this, but in this scenario there's a group chat so it's more complicated. The threads that I have read suppose that it's a chat between two people.
I have thought about having a new collection seenMsgTimestamps where I store the timestamp of the last message that a certain user has seen for each group chat. In my app, I will listen to changes to messages starting from the the timestamp found in seenMsgTimestamps for that chat, and count how many new messages are there.
Is this a good approach or is there a better way of doing this?
Thanks in advance.
In my opinion you an go ahead with this solution. Why is this solution good?
I have thought about having a new collection seenMsgTimestamps where I store the timestamp of the last message that a certain user has seen for each group chat.
You denormalize data by creating a new collection, which is a quite common practice when it comes to NoSQL databases. In your particulasr case, I think is the best solution.
In my app, I will listen to changes to messages starting from the the timestamp found in seenMsgTimestamps for that chat
That's also good because you are using a query on a limited data set and not on the entire collection, which means less reads, less money to pay but more perfomance.
Regarding the count, I recommend you also read the last part of my answer from this post. So you can also consider using Firebase realtime database for such conters.
I'm creating a chrome extension that allows users to chat with one another. I've finished the basic implementation and want to add notifications that tell a user if they've received a new chat message since the last time they were connected. I have an idea of how I want to implement it but need input on whether it seems feasible and suitable.
Basically, my database is structured so that there is a list of users and chatrooms. Each user has a section called chats which lists all the names of the chatrooms they're in:
What I plan to do is the following: In every chat under each user's chats section, instead of setting its value to true, I set it to the last time they disconnected. Then in each chatroom, I add another field after user2 called timeLastMessageSent and always update it to the current time a new message is sent.
With that information, every time a user connects I'll loop through the chatroom's listed in their chats section and see if the value of timeLastMessageSent is higher than their last disconnect time, which means a message was sent while they were away and I can add some sort of notification that they have a new message.
I'm relatively new to firebase so if anyone with more experience can tell me what they think of my idea I'd really appreciate it. Is this idea feasible? Am I approaching the problem correctly? What sort of commands should I get familiar with to achieve this?
In the firebase example (https://gist.github.com/anantn/4323981), to add an user to the game, we attach the transaction method to playerListRef. Now, every time firebase attempts to update data, it will call the callback passed to the transaction method with the list of userid of all players. If my game supports thousands of users to join at a time, every instance this method executes, the entire user list will be downloaded and passed which will be bad.
If this is true, what is the recommended way to assign users then?
This is specifically what Firebase was designed to handle. If your application needs to actually assign player numbers, this example is the way to go. Otherwise, if the players just need to be in the same "game" or "room" without any notion of ordering you could remove the transaction code to speed things up a bit. The snippet as well as the backend have handled the number of concurrent connections you've mentioned—if you're seeing any specific problems with your code or behavior with Firebase that appears to be a bug, please contact us at support#firebase.com and we can dig into it.