CODEWITHSUNDEEP
iosswiftfirebasegoogle-cloud-firestore
Chris
Chris

Reputation: 282

Querying Firebase Firestore Data

I'm looking to build an app that functions like a dating app:

  1. User A fetches All Users.
  2. User A removes Users B, C, and D.
  3. User A fetches All Users again - excluding Users B, C, and D.

My goal is to perform a query that does not read the User B, C, and D documents in my fetch query.

I've read into array-contains-any, array-contains, not-in queries, but the 10 item limit prevents me from using these as options because the "removed users list" will continue to grow.

2 workaround options I've mulled over are...

  1. Performing a paginated fetch on All User documents and then filtering out on the client side?

  2. Store all User IDs (A, B, C, D) on 1 document in an array field, fetch the 1 document, and then filter client side?

Any guidance would be extremely appreciated either on suggestions around how I store my data or specific queries I can perform.

Upvotes: 0

Views: 149

Answers (2)

slushy
slushy

Reputation: 12385

This is how I'd approach it. The user (user-A) queries a pool of people, and each person is represented by their own document. user-A must then take an action on each person (document), and, presumably, when an action is taken that person should no longer reappear in user-A's queries. We shouldn't edit the queried documents because then every user would edit the same documents and documents have byte and write limits. And we shouldn't use arrays either for the same reasons. Instead, we should treat a collection like an array using documents as items, since collections don't have document limits.

Therefore, whenever user-A takes an action (swipe left/right) on someone else (user-X), create a new document in a subcollection under user-A that simply contains the uid of user-X, and perhaps a boolean like didLike, and perhaps a timestamp--we never know when these may come in handy.

When user-A performs another query at some point in the future, user-X is going to reappear in the results, which we now need to filter out. All we must do is check the user-A subcollection for user-X. If user-X is in this subcollection, omit the document and move on to the next person. If the UI is configured like Tinder's, where there isn't a list of people to scroll through but instead cards stacked on top of each other, this is no big deal. user-A will only be presented with one person at a time and they won't know how many we're filtering out behind the scenes. With a scrollable paginated list, however, user-A may see odd behavior like uneven pages.

This model can scale to virtual infinity.

Upvotes: 0

Sebastian Fox
Sebastian Fox

Reputation: 1521

You can do it the other way around.

Instead of a removed or ignored array at your current user, you have an array of ignoredBy or removedBy in which you add your current user. And when you fetch the users from the users collection, you just have to check if the requesting user is part of the array ignoredBy. So you don’t have tons of entries to check in the array, it is always just one.

Upvotes: 1

Related Questions