0

I have this list of messages objects, with a message, a user_id and a date. I actually want to retrieve user informations together with each message.

return new Promise<any>((resolve, reject) => {
  this.afs.collection('/messages").snapshotChanges()
    .subscribe(snapshots => {
      resolve(snapshots)
    })
})

I don't think iterating on the messages to get users is what I want to do - there should be a much better way. I'm also not sure about the recommandations I read at some places about storing the whole user data for each location where you could need it... I don't like it.

Is there a better way ?

Jeremy Belolo
  • 4,319
  • 6
  • 44
  • 88
  • If you are interested, here you can find the [database schema](https://www.youtube.com/watch?v=u3KwKQddPoo&t=176s&index=3&list=PLn2n4GESV0Ak1HiH0tTPTJXsOEy-5v9qb) for a chat app in which you have all user details in every place are needed. – Alex Mamo Oct 24 '18 at 06:25

1 Answers1

0

This question is answered here by Frank from Firebase here in relation to the Realtime Database. This will most likely be applicable to your use case as well. There is also a great little support document listing out the advantages of the different approaches with Firestore here.

Depending on your specific use case, it might or might not be tenable to store user data in your message object. You might have heard of data duplication and de-normalisation which is a common practice in NoSQL databases.

Without knowing too much about your use case, I would store user_id's on the message object and fetch them if and when they are needed.

Chris
  • 7,830
  • 6
  • 38
  • 72
  • As I said, that's what I did; I store the user_id on the message object. And thank you for the link, it's nice to refresh a little about how to structure data ! The question, though, is about the possibility to fetch user's data from USERS node directly when fetching the message that have a user_id, instead of waiting for the response and then get each user's info through a loop. – Jeremy Belolo Oct 22 '18 at 18:57