How to organize FireStore Collections and Documents based on app similar to BlaBlaCar rides

Question

It's my first time working with FireStore. I'm working on a ridesharing app with Flutter that uses Firebase Auth where users can create trips and offer rides similarly to BlaBlaCar, where other users can send requests to join a ride. I’m having difficulty not only deciding the potential collections and paths to use, but also how to even structure it.

For simplicity at this stage, I want any user to be able to see all trips created, but when they go to their “My Rides” page, they will only see the rides that they’ve participated in. I would be grateful for any kind of feedback.

Here are the options I’ve considered:

1. Two collections, “Users” and “Trips”. The path would look something like this: users/uid and trips/tripsId with a created_by field

2. One collection of “Users” and a sub-collection of “Trips". The path seems to make more sense to me, which would be users/uid/trips/tripId but then I don't know how other users could access all the rides on their home feed.

I'm inclined to go with the first option of two collections. Also very open to any other suggestions or help. Thanks.

Answer 1

I want any user to be able to see all trips created, but when they go to their “My Rides” page, they will only see the rides that they’ve participated in

I make the assumption that participating in a ride is either being the author or being a passenger of the ride.

I would go for 2 collections: one for users and one for trips. In a trip document you add two fields:

• createdBy with the uid of the creator
• participants: an Array where you store the author's uid and all the other participants uids (passengers)

This way you can easily query for:

• All the rides
• All the rides created by a user
• All the rides for which a user is a participant, using arrayContains.

(Regarding the limit of 1 MiB for the maximum size for a document I guess this is not a problem because the number of passengers of a ride shouldn't be so huge that the Array fields size makes the document larger than 1 Mib!)

---

Note that the second approach with subcollections could also be used since you can query with collections group queries but, based on the elements in your question, I don't see any technical advantage.