22

The simplest way of storing chat messages is probably this:

message:
 -message1 {
   "user1"
   "user2"
   "message"
   "date"
  }
 -message2
 -message3

When the app grows in size (a lot of messages), and operations on database are done with .whereEqualTo are there any disadvantages of structuring chat app messages this way? Like with database iterating through all messages ?

Because if there are problems with this approach, i've seen for example this way of structuring database, that would segregate messages in different chat rooms

chats: {
    -chat1 {
      "lastMessage"
      "timestamp"
      "users": {user1, user2}
    }
    -chat2
    -chat3
  }

messages: {
 -chat1 {
  "message"
  "date"
 }
}

But in this example, adding new message would require user to make 2 write operations, one writing new message and one updating chat document with new lastMessage and timestamp client-side, or creating a cloud function to update chat document with new values, when new message is added.

So, is the first option valid, or should I go with something like the second example?

Wiktor
  • 885
  • 1
  • 9
  • 23
  • If you are interested, you can also take a look at this [chat tutorial](https://www.youtube.com/playlist?list=PLn2n4GESV0Ak1HiH0tTPTJXsOEy-5v9qb). This is the [Firestore database schema](https://www.youtube.com/watch?v=u3KwKQddPoo&t=1s&list=PLn2n4GESV0Ak1HiH0tTPTJXsOEy-5v9qb&index=3). – Alex Mamo Jan 03 '19 at 16:10

1 Answers1

44

What you've offered as the first option is close to how you'd model this in a relation database in a tblMessages. Such a literal translation is seldom your best option in NoSQL databases, since they have very different trade-offs. For example, you've already noticed that you need to perform a query on two fields to get the messages between two users.

When modeling data on a NoSQL database, I usually recommend modeling in your database for what you see on your screen. So if your chat app has the concept of chat rooms (i.e. persistent chats between specific groups of people), I'd model those in your database too.

In Cloud Firestore that means that you'd have a top-level collection with a document for each chat room, and then a subcollection under each such document with the messages for that chat room:

ChatRooms (collection)
  ChatRoom1 (document)
    Messages (collection)
      Message1_1 (document)
      Message1_2 (document)
  ChatRoom2 (document)
    Messages (collection)
      Message2_1 (document)
      Message2_2 (document)

With this model you don't need to query to show the messages in a chat room, but can instead just load (all) the messages straight from the subcollection for that room. It also has the advantage that you partition the rooms, meaning that writes can scale much better.

I typically recommend modeling the chat room document IDs after the participants in the room, so that you can easily reconstruct the ID based on the participants. But there are more valid options for this.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • So that's something like my second option, but combined to one collection, because if I wanted to add a listener to notify user of new message in any of those chatRooms i still need to keep something like `lastMessage` in `chatRoom` document, right? – Wiktor Jan 02 '19 at 15:08
  • 1
    I typically prefer to precalculate anything I can, so would definitely have a `lastUpdated` field in each room document. – Frank van Puffelen Jan 02 '19 at 15:43
  • 1
    You can find a similar use case in their official documentation. https://firebase.google.com/docs/firestore/data-model – Madura Pradeep Aug 29 '19 at 15:19
  • My answer in the question I linked shows how to do create a list of chat rooms for each user. – Frank van Puffelen Apr 18 '20 at 14:23