CODEWITHSUNDEEP
databasefirebasegoogle-cloud-firestorenosqlsocial-networking
Martin Petts
Martin Petts

Reputation: 513

Firebase Firestore data structure for social network blocking profiles

I'm building a social network using Firebase Firestore and I have a question about data structure for the functionality that enables users to block each other.

At the moment I have a collection called "blocking" which has two sub-collections, e.g.:

/blocking/{uid}/userBlocking/{targetUid} <-- the uids the user is blocking
/blocking/{uid}/userBlocked/{targetUid} <-- the uids the user is blocked by

When a user views a profile I check to see if the user is blocking the profile or if the profile is blocked by the user, which seems fine.

However, for each post I also need to check if the post author is blocked/is blocking and for each comment on the post as well. In a list of 25 posts that's an extra 50 calls to Firestore just for the post object and who knows how many for the comments, which seems suboptimal and excessive for functionality that I hope won't be used that much.

I could store the blocked/blocking uids as arrays in the user profile (the users collection doc), but this could potentially become unwieldy and bloat the profile document.

How would you do this?

Upvotes: 3

Views: 534

Answers (1)

Doug Stevenson
Doug Stevenson

Reputation: 317740

I think what you're doing is actually the best possible situation. You've correctly identified that there's a tradeoff between scalability and cost, which is a very common thing for NoSQL type databases to manage. If you want scalability, you're going to have to accept the cost.

You can optimize this by writing your client code to only check the local cache for each document get(), and only periodically refresh the cache, loading new documents as needed.

Upvotes: 1

Related Questions