0

If I fan out my data like this in Firebase (for a social network):

post
     postId
          postText: This is a post
          postedBy: bob

comment
     commentId
          commentText: This is a comment
          postedBy: fred

like
     likeId
          postedBy: george

Then when I want to build a tableview of posts I have to embed a LOT of observers. For example:

ref.child("post").observeSingleEventOfType(.Value, withBlock: {
     ref.child(userId).observeSingleEventOfType(.Value, withBlock: {
     })
})

That is needed to get the post data and the user data if you want to pos the user's name and whatever else. Then if you want to do number of likes you have to embed it inside, and if you want to do some preview comments like Instagram does, you have to embed another... and if you have more creative things to add it goes on and on like so:

    ref.child("post").observeSingleEventOfType(.Value, withBlock: {
         ref.child(userId).observeSingleEventOfType(.Value, withBlock: {
              ref.child("comments").observeSingleEventOfType(.Value, withBlock: {
                   ref.child(commentUserId).observeSingleEventOfType(.Value, withBlock: {
                        ref.child("likes").observeSingleEventOfType(.Value, withBlock: {
// create post object here and append to array
                    })
               })
          })
     })
})

So anyway it gets pretty crazy if you want to get the people who liked, and have more stuff to add. My question is, is this okay to do in Firebase and does this make the fan-out data methods still worth using? I feel like it would slow it down so much that we would be better off just putting all the stuff underneath the post object in Firebase. I did read that observers aren't very expensive but it didn't say much about nesting them.

Wayne Filkins
  • 494
  • 6
  • 20
  • There are times to denormalize and times it's not applicable. In this use case, the comments appear to be tied to a specific post as well as the likes. Those could certainly live in the post node. That would reduce the observers to one. However, if you are going to query, sort or other functions that may not be the best path. It really depends on how you are using the data and there's not enough info in the question to make that determination. The quantity of data could play a role as well. – Jay Nov 17 '16 at 01:54
  • In general developers overestimate how slow the client-side joins become. Firebase handles them quite efficiently, because it [pipelines the requests](http://stackoverflow.com/questions/35931526/speed-up-fetching-posts-for-my-social-network-app-by-using-query-instead-of-obse/35932786#35932786). But five levels of nested listeners feels like a bit much, mostly because the code gets unreadable. You could also duplicate some of the data, to prevent that level of nesting. But as Jay says: it's hard to give more specific advise, since it depends on the app. – Frank van Puffelen Nov 17 '16 at 12:36
  • @FrankvanPuffelen Another good way for me to ask this would be: Is nesting 5 observers the same as having 5 observers which aren't nested? In other words, do they take the same resources if they were just side by side but giving me the same amount of data? – Wayne Filkins Nov 17 '16 at 20:17

0 Answers0