Firestore with GeoFlutterFire - Is there a more efficient way for nearest users + liked/disliked filter?

Context

My app uses a similar functionality like Tinder:

1. Get nearest users (geohash filter + some others)
2. User can like/dislike users
3. On subsequent launches, user needs to see NEW users, without those he or she already liked/disliked

Current structure looks like this:

This is my code so far:

UserRepository:

  // Geohashing with GeoFlutterFire2
  Stream<List<DocumentSnapshot>> getAllUsersInRadius(
      {required LocationData currentLocation, required double radius}) {
    String field = 'position';

    GeoFirePoint centerPoint = _geo.point(
        latitude: currentLocation.latitude ?? 0.0,
        longitude: currentLocation.longitude ?? 0.0);

    return _geo
        .collection(collectionRef: _buildUserQuery())
        .withinAsSingleStreamSubscription(
            center: centerPoint, radius: radius, field: field);
  }

  // The query to pre-filter BEFORE the geohash query
  Query<Map<String, dynamic>> _buildUserQuery() {
    // Filter by 1. location (above), 2. isActive, 3. game list, 4. user type
    var query = _firestoreDB
        .collection(userCollection)
        .where("isActive", isEqualTo: true)
        .where("gameList", arrayContainsAny: ["Example1","Example2"])
        .where(Filter.or(Filter("userType", isEqualTo: currentUser.lookingFor[0]),
            Filter("userType", isEqualTo: currentUser.lookingFor[1])));

    return query;
  }

  // UserRelations = list of liked/disliked other users
  Future<List<String>> getUserRelationIDs(String userID) async {
    List<String> result = [];

    await _firestoreDB
        .collection(userCollection)
        .doc(userID)
        .collection("user_relations")
        .get()
        .then((querySnapshot) {
      for (var doc in querySnapshot.docs) {
        final otherUserID = doc.data()["otherUserID"];
        result.add(otherUserID);
      }
    });

    return result;
  }

UserViewModel:

  Future<void> _getAllUsersInRadius() async {
    currentLocationValue = await _userRepo.getCurrentUserLocation();
    await _userRepo.getCurrentUser(_authRepo.user!.uid);

    if (currentLocationValue != null) {
      // Needed for later filtering
      final userRelationIDs =
          await _userRepo.getUserRelationIDs(_userRepo.currentUser!.uuid);

      var subcription = _userRepo
          .getAllUsersInRadius(
              currentLocation: currentLocationValue!, radius: 2000)
          .listen((documentList) {
        // First, filter out all users that were already liked/disliked by currentUser
        var filteredUserList = documentList.where((docSnapshot) {
          if (!docSnapshot.exists || docSnapshot.data() == null) return false;
          String uuid = docSnapshot.get("uuid");
          if (!userRelationIDs.contains(uuid)) return true;
          return false;
        });
        // Now turn all documents into user objects and publish the list
        allUsersList = filteredUserList
            .map((docSnapshot) => _createUserFromSnapshot(docSnapshot))
            .toList();
        _allUsersStreamcontroller.add(allUsersList);
      });

      subscriptions.add(subcription);
    }
  }

My Problem

I see the following points as problematic:

• It feels very inefficient to load all the users first and then possibly discard most of them -> wasted reads/month
• Due to using a geo-query (GeoFlutterFire2), I am very limited in the other filters I can apply (no ranges or sorting, since that is already used for the geohash) -> so I don't have a lot of options on the query side

So what I am wondering is: is there a more performant/efficient way to go about this?

Maybe by structuring the data differently?

I may have a solution in a limited case, it assumes:

• that you users can only set their location once
• you are using geohashes to encode the user's positions
• that the radius on which a search is made is static. Say 3km corresponding to geohash5

The idea is to "include" users in your query rather then "excluding" them, which Firestore cannot do well:

1. When a user sets its location, it is assigned a unique number per geohash5, a number starting at 1 for the first user and incremented for each new user

2. The total number of users per geohash5 is also stored in a central document

3. When your app picks a list of users to show, it will

   a. Select the geohash5 currentgeohash5 to use, the one of the user

   b. Pick the numbers [no1, ..., no10] of the users to show between 1 and the max for this geoash5 (step 2 above), but only among those that have been neither liked, nor disliked

   c. Query new users with

   .where("geohash5", "==", currentgeohash5)
   .where("no", "in", [no1, ..., no10])
   

   d. Also store locally any likes and dislikes so you dont have to load them from Firestore at step 3.b

Note: when using geohashes this way you also need to account for the frequent case of your user being close to the edge of its geohash, in which case you also want to include some of the ones around. But the algorithm works just the same way.