Nested stars in the Firebase database

I find the Firebase sample database very useful, but I noticed something that bothers me a bit.

I mean, in this example, the user can give the star a message, something like “Like it” on Facebook. In the presented sample, they insert stars in the message, so we have an example of an object as follows:

"post_id" : { "author": "username", "body": "Some content", "starCount": 1 "stars" : { "user_id_who_gave_star" : "true" } "title": "Some title", "uid": "author_id" } 

Such a solution has many advantages, such as, for example, we can check whether the star icon is already indicated and hide or change, or we can change the starCount one transaction and add the next value to the stars.

But the problem is that we have a large application, and 1000 users gave a star, so every time we download postdata, we load 1000 userIds, which may not be the best solution.

Question

My question is what works best for such applications and someone tested how Firebase works in this situation?

0
source share
1 answer

firebaser here

When writing examples of our documentation, we always need to balance the need for sufficient context, keeping the example small enough and following our own best practices.

This is truly one of the cases where we violate one of our own best “non-nested data” methods. As you said: this means that the user downloading the message receives all the UIDs of users who liked this post.

Like using application scales, this can be a problem. If this is the case for your application, you should model the “users who raised the message” as a separate top-level node:

 "posts": { "post_id" : { "author": "username", "body": "Some content", "starCount": 1 "title": "Some title", "uid": "author_id" } }, "upvotes": { "post_id" : { "user_id_who_gave_star" : "true" } } 
+1
source

Source: https://habr.com/ru/post/1262324/


All Articles