Firebase mimicing WHERE IN

Question

Given the date model provided below, after a user logs in and retrieves their data, they can also get a list of their friends.

However, in order to now attain details of those two friends by ids fdb17f3a-7b7d-4aa5-9a0b-b9fb33c349de and a96da7b1-7c4e-44bc-b82e-fc75bed52bcd, at present, the most efficiently operation appears to simply be to loop through the urls, in such a way as:

for singleFriendID in allFriendIds

    firebase.com/[my_db_name]/users/{singleFriendID} 

end

but even that has its major limitations, if say you want a list of usernames of your 40 friends, you now need 40 individual, specific calls, to the server...

How can I efficiently lookup data within Firebase instead of dumping all the friend details to their phone?

Firebase schema:

{  
   "users":{  
      "99e4989b-a046-4c5f-9478-5ebd8bdc3ded":{  
         "email":"[e-mail]",
         "friends":{  
            "fdb17f3a-7b7d-4aa5-9a0b-b9fb33c349de":{  
               "confirmed":true,
               "selfSendRequest":false,
               "timeInvited":"2016-02-21 08:49:31"
            },
            "a96da7b1-7c4e-44bc-b82e-fc75bed52bcd":{  
               "confirmed":true,
               "seldSendRequest":false,
               "timeInvited":"2016-02-21 08:49:31"
            }
         },
         "password":"aPassword",
         "phoneNumber":"16144444444",
         "username":"person2"
      }
      "a96da7b1-7c4e-44bc-b82e-fc75bed52bcd": {
      ...
      ...
   }
}

Answer 1

There is no need to do 40 calls to the db. You simply keep a list of friends per user (with each object containing every user info that you might need):

/users/:id:/friends

So when you want a list of your friends:

/users/:myId:/friends

Which will give you a list (with one call!), which you can loop through. So there is no need to do a separate call for every specific user endpoint.

There is no problem with having duplicate data in your db to improve performance!

Update (to answer the comment):

To show friends of a user or for example a list of people who have liked a photo, it usually suffices to only store IDs and names. To show more information, the profile of that particular user could be shown on click event.

Answer 2

Loolooii's approach will save on the number of calls and is definitely a valid approach.

But you're also making the assumption that 40 calls to the Firebase database is a lot. If you take a moment to measure this, you'll probably be surprised.

In traditional databases, you do a roundtrip to the database for each call.

client                   server
    --- give me item 1 --->
                             loading
                             item 1
    <-- here is item 1 ----
    --- give me item 2 --->
                             loading
                             item 2
    <-- here is item 2 ----
    --- give me item 3 --->
                             loading
                             item 3
    <-- here is item 3 ----
    --- give me item 4 --->
                             loading
                             item 4
    <-- here is item 4 ----

Firebase pipelines all the requests. So essentially the clients immediately send the requests for all items in quick succession:

client                   server
    --- give me item 1 --->
    --- give me item 2 --->
    --- give me item 3 --->
    --- give me item 4 --->
                             loading
                             item 1
                             loading
                             item 2
                             loading
                             item 3
                             loading
                             item 4
    <-- here is item 1 ----
    <-- here is item 2 ----
    <-- here is item 3 ----
    <-- here is item 4 ----

You'll find that this is much faster, since you're only waiting for 1 roundtrip, plus the time to load the items. If that last bit is concerning, take Loolooii's approach.