Storing a tree structure in firebase

[Jordan Schroter]

I'm just starting with firebase and I'm wondering if there are any best practices for storing a tree-like data structure in firebase. 

My current thoughts are to flatten all the nodes but store a child and sibling key on each node to create the relationships:

/*

node1 ----- node3

  |

node2 ----- node4

                     |

                 node5

*/

nodes: {
  node1: {
   child: 'node2',
   sibling: 'node3'
   ...
  },
  node2: {
    child: null,
    sibling: 'node4'
    ...
  },
  node3: {
    child: null,
    sibling: null
    ...
  },
  node4: {
    child: 'node5',
    sibling: null
    ...
  },
  node5: {
    child: null,
    sibling: null
    ...
  }
}

Are there any problems with this approach given users are going to be manipulating the same tree (adding nodes, removing, reordering, etc...) in real-time?

I also thought about storing the reverse relationship ie. parent and previous sibling rather then child and next sibling but not sure if that's any better. It would help me find the root node easier (parent == prevSibling == null) but would make traversing more difficult.

Any insights are appreciated.

Thanks,

Jordan

[Jacob Wenger]

Hey Jordan,

I think the answer to your question highly depends on what type of operations you will be doing on the tree. It seems like a lot of work to store the tree in a flat data structure. One of the reasons why trees are so handy is that their structure allows for a lot of different quick operations. However, once you flatten the tree, you lose a lot of that advantage. And iterating over a tree in Firebase is probably not going to really be very efficient unless you load the whole tree in memory at the start, which probably is not what you want.

This is a bit of an XY problem, so please share your use case and then we can go from there.

Jacob

P.S. In case you don't know, we have a whole guide section on structuring data in Firebase which may help you out here.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/542f8667-a2fa-4101-89a4-92c0c72c162b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jordan Schroter]

Hey Jacob,

Thanks for your response, apologies if I didn't include enough information in the original post to help. What I'm trying to do is build an application that lets users create widgets by composing components together. Components can be nested similar to any React application to build these widgets so I don't think there will be so many nodes in a tree that I wouldn't download them all. My original thoughts behind flattening the data was after reading the docs and so its easy to lookup and update a single node's data rather then traversing the tree. 

Hope that helps.

[Jacob Wenger]

Hey Jordan,

Thanks for clarifying things. In your use case, I don't see a lot of benefit in storing the tree in a flat data structure. The two main benefits of doing that is that you have one source of truth which you can just link to from anywhere else in your Firebase and that you don't have to download all the data until you actually need it. The first isn't really relevant to your situation since it sounds like each node will be unique and the second is moot if you are downloading all of the tree anyway. I'm not saying to not do it (you totally can and I'm sure it will work), but you probably don't gain a lot from it. It seems weird to me to take a tree-like data store (Firebase) and a tree-like data structure (your components) and coerce them into the flat data structure you suggest. I think this is a case of our "best practices" not really applying to this use case.

Jacob

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/bf4bcf34-4182-46f4-8625-90406f17d655%40googlegroups.com.

[Jordan Schroter]

Thanks Jacob, your insight it much appreciated. I haven't actually implemented anything yet and doesn't sound like there's a clear right or wrong solution in this case so I will give this post an update with what I end up going with.

Jordan