angularjs - Drafts & Publishing in Firebase -

building cms , trying find out best way handle drafts firebase. example, site administrators edit documents, published publicly site.

at first seemed perfect solution have "public" property set true , enforce via security rule follows:

{   "rules": {     "documents": {       "$id": {         ".read": "data.child('public').val() == true"       }     }   } } 

(as documented here: https://www.firebase.com/docs/security/rule-expressions/data.html)

but apparently documentation flawed because in example can hit /documents , give me documents regardless of 'public' == true. prevent have change to:

{   "rules": {     "documents": {       ".read": false,       "$id": {         ".read": "data.child('public').val() == true"       }     }   } } 

ideally i'd able expose simple rest api endpoint /documents/ returned public documents child properties.

apparently firebase doesn't support filtering (which trying saying "select * documents public = true".

so see 2 options:

option 1: keep rest api endpoint nice & clean storing document drafts in different place (like /drafts/documents). administrators create & edit draft documents auto-save , have "publish" button when clicked copy current drafts public /documents.

option 2: not have clean rest api endpoint of /documents , instead have /documentindex returns list of document ids. client have iterate through each documentindex call each individual document endpoint @ /documents/:id. worry performance option. option seems documented here: firebase data normalized. how should fetch collection based on structure? doesn't cover implications rest api. i'm using angularjs other client's might want consume document data in other ways (hence why want expose data via rest api well).

thoughts?

both approaches ones. index more flexible when structure , ordering change or when multiple ordering possibilities exist (e.g. list ordered date , rank). additional listeners don't have affect on performance (it's not more time required fetch bytes).

moving data between paths, sort of queue or folder approach, may work needs, since you've emphasized rest access. if, unlike specific use case, 1 wanted move large amounts of data in bulk (several hundred megs) not great approach since requires downloaded data client before writing new path.

if goal optimize possible other clients you're going need start determining , how connecting. it's difficult make intelligent decision based purely on possibilities.

before bothering optimizations purely rest, i'd first try bit of profiling see how performs. may find plenty sufficient use cases have in mind.