Using firebase tree structure to represent a "document outline" structure directly -
how good/stupid use firebase tree structure directly represent user-facing tree structure, "document outline" in "word processors"? opposed e.g. doing sql-join parent-child type of relationship , building tree via projection (which slow).
i know there limit of 32 levels of nesting ( https://www.firebase.com/docs/web/guide/understanding-data.html ), should enough, cannot imagine sane user wanting many levels of nesting textual tree-outline... although maybe need divide 32 two, because of each node needing have sub nodes children , metadata, right?
i know once tree node accessed via firebase api, sub-nodes need fetched, performance problem if user has lot of data, in end think not problem, since data user-entered plaintext (short).
a performance problem arise if user pastes long chunks of text copied somewhere (e.g. tens of kilobytes). separate "tlob-s" via kind of "symlink" in firebase , fetch them on-demand different node, right? same should apply separating images , other heavy objects, right? although in prototype , stages, should ignored, sake of simplicity... put in place generic approach "symlinking", overcome 32 levels limitation , need fetch sub-nodes @ once, right? there best-practices approach (e.g. syntax firebase node symbolise link node) ? have extracted "symlinking" idea separate question: firebase "symlink" node .
i partition topmost nodes kinds of projects/categories prevent having fetch absolutely user has ever had...
is reasoning/approach correct?
is there consideration did not think of, e.g. innate limits on data size or performance or e.g. security rules?
would better served other technologies couchbase/pouchbase ?
further details: hybrid mobile app emphasis on web access , offline access. hope of logic in javascript. ui part of question here: html tree hybrid mobile app .
Comments
Post a Comment