Discussion on Firebase NoSQL Database and Data Structure

[mufniarz]

Hi everyone,

I would like to open a discussion on the use of Firebase's NoSQL database Firestore for our project. I believe this platform could provide several advantages for our specific needs, but it also comes with some potential drawbacks.

Pros:

1. Real-time updates: Firestore can push updates to the client in real-time. This can be a significant advantage for features that require live updates.

2. Scalability: Firestore is built to scale automatically, which could be beneficial as our user base grows.

3. Integration with other Firebase services: Firestore can be seamlessly integrated with Firebase's other offerings, like Authentication, Storage, and Cloud Functions.

4. Strong SDKs and Libraries: Firebase provides powerful SDKs and libraries that allow for easy integration into various platforms including Android, iOS, and Web.

Cons:

1. Complex Queries: Firestore has certain limitations with complex queries, unlike SQL databases which allow for complex joins and aggregations.

2. Cost: Firestore charges based on the number of reads, writes, and deletes. Depending on the usage pattern, this can become costly.

3. Data Structure: NoSQL databases like Firestore require careful planning of data structure. Since it's a document database, you have to consider how data is nested or referenced.

For our project data, I propose structuring it as follows:

Users Collection:

{
  id: 'user-id',
  name: 'user-name',
  email: 'user-email',
  profilePicture: 'url-to-profile-picture',
  bio: 'user-bio'
}

Groups Collection:

{
  id: 'group-id',
  name: 'group-name',
  groupPicture: 'url-to-group-picture',
  description: 'group-description',
  members: ['user-id1', 'user-id2']
}

This structure would allow us to efficiently fetch user and group information while minimizing document reads.

I would love to hear your thoughts and suggestions on this. Do you think Firestore is a good fit for our needs? Is there anything we should consider in structuring our data?

Thank you!

[mufniarz]

Hi everyone,

I'd like to further elaborate on the cost aspect of Firebase Firestore.

Firestore's pricing model is based on the number of reads, writes, and deletes, rather than the amount of data stored. While this seems straightforward, it can lead to unexpected costs if not carefully managed.

For instance, suppose our app has a feature where a user can like a post, and we have implemented it in such a way that every like increments a 'likeCount' field in the post document. If we have a large user base, this could quickly result in a significant number of writes, thus increasing costs.

On the other hand, Firestore's pricing model can also be an advantage in certain scenarios. If we structure our data efficiently, we can minimize the number of reads/writes required for each operation, effectively controlling costs.

For example, in the proposed group data structure:

{
  id: 'group-id',
  name: 'group-name',
  groupPicture: 'url-to-group-picture',
  description: 'group-description',
  members: ['user-id1', 'user-id2']
}

Instead of keeping an array of user IDs in each group document (which could lead to a high number of reads/writes every time a user joins or leaves a group), we could create a separate 'groupMembers' collection where each document represents a user's membership in a group. This would allow us to only read/write documents that are directly relevant to the operations being performed, thus optimizing costs.

In summary, while Firestore's pricing model has its challenges, with careful data modeling and efficient querying, we can mitigate potential cost issues. I'd love to hear any other strategies or experiences you've had with Firestore's pricing!

[mufniarz]

Hi everyone,

I've updated the Wiki to include a Firebase Database Structure page. In it I've broken up members into a new subcollection of groups. In NoSQL, it looks like the preferred method of storing data is by denormalizing it to the point where you don't need joins in order to get all the data you need. Please keep that in mind when you see duplicate data across multiple collections.

[mufniarz]

Firestore is a NoSQL database and has two primary data types: collections and documents. Collections are containers for documents, and documents are individual entries containing fields (which hold the data). Here are a few ways you can structure your user and group data in Firestore:

1. Flat Structure (A collection for each entity):

   Users Collection:

   • users/{userId}
     • Fields: name, email, profilePicture, etc.

   Groups Collection:

   • groups/{groupId}
     • Fields: groupName, groupDescription, groupIcon, etc.

2. Subcollection (Nested data):

   Users Collection:

   • users/{userId}
     • Fields: name, email, profilePicture, etc.
     • Subcollections: userGroups/{groupId}

   Groups Collection:

   • groups/{groupId}
     • Fields: groupName, groupDescription, groupIcon, etc.
     • Subcollections: groupMembers/{userId}

3. Combination of both (For frequently accessed data):

   Users Collection:

   • users/{userId}
     • Fields: name, email, profilePicture, etc.
     • Array: groupIds

   Groups Collection:

   • groups/{groupId}
     • Fields: groupName, groupDescription, groupIcon, etc.
     • Array: memberIds