Reducing Calls to Firebase vs Reducing Data Redundancy

Viewed 284

Currently developing an app with a Chat Feature and was wondering if I should prioritize in minimizing the calls to the DB or minimize the data redundancy in the DB.


Sample DB structure

For the users part:

users/
  active/
    $uid/ (Firebase Auth generated)
      username: string
      userPhotoUrl: string

For the chat messages part:

messages/
  chatRooms/
    $chatRoomId/
      dateCreated: timestamp
      title: string

  chatMessages/
    $chatRoomId/
      $messageId/
        createdAt: timestamp
        uid: string
        message: string

As seen in the DB structure, if I retrieve the chat objects (messageId) I'd only be able to retrieve createdAt, uid, message. This is working fine, however, I would also need the username and userPhotoUrl in order to show the desired data on the client side.

Approach: A flow to get the data I need is to make two calls to the DB, one is to get the data from chatMessages node and the other on the users node.

There are two scenarios where I would need these data:

  1. Retrieving multiple chat messages (initially and every time the user decides to view older messages).
  2. A new chat message is saved to the DB.

For the first scenario, what I would have to do is to first retrieve the list of chatMessages, upon getting them successfully, I would then need to make a call to DB to get the user details (username, userPhotoUrl) for each chat message -- in order to avoid redundancy of calls as well, I'm saving each user details locally (in SharedPrefs), so that if it already exists, I would just get it immediately.

  • Pros: Minimizes data redundancy in Firebase DB, which saves space.
  • Cons: This involves a lot of API calls and would increase the time to actually be able to display the chat messages.

Possible workaround to make things simpler is to have a username and userPhotoUrl for each chat message. E.g.:

$messageId/
  createdAt: timestamp
  uid: string
  username: string
  userPhotoUrl: string
  message: string
  • Pros: Easier retrieval since it would just be a single call.
  • Cons: Data redundancy would be too much.

For the second scenario, I would have to do the same approach every time I detect a child is added to the $chatRoomId. Same pros and cons.


I understand that data redundancy in NoSQL DB is fine, but for a chat app that would contain a lot of messages, and where the message is the data that could contain redundant data, I think it would be quite heavy stored data wise.

Question is, am I right to aim for reducing the data redundancy, trading a lot of API calls in turn? If anyone could suggest a better approach that I might be missing, it'd be appreciated.

0 Answers
Related