Firebase Realtime database structure best practice question










1















I am trying to figure out best practices for a Firebase Realtime database structure when securing data. I have read about how to secure the database using Firebase Realtime Database Rules.



For example:
A user adds "notes" and shares those "notes" with other users (members) who can then edit and comment those "notes".
Lets consider a storage structure like the one below:



-categories
-uuid-cat1
-data
title: "my category 1"
-members
author: "uuid-user1"
-notes
-uuid-note1
-data
title: "Hello World!"
categoryId: "uuid-cat1"
-comments
-uuid-comment1
title: "Can you explain?"
author: "uuid-user2"
-uuid-comment2
title: "Certainly!"
author: "uuid-user1"
-members
author: "uuid-user1"
uuid-user2: "uuid-user2" //UPDATE 2 - This is another user with access to the note
-uuid-note2
-data
title: "Hello Universe!"
-categoryIds
uuid-2: "uuid-cat2"
-members
author: "uuid-user2"
-users
-uuid-user1
name: "Jane"
-uuid-user2
name: "Jane"


Users only have access to notes or categories if they are listed as "members/author" or "members/user-id". This is enforced by Firebase Realtime database Rules.



Would this work in on a larger scale?
Let's say we store 200 000 notes.



When requesting to read all "notes" from the database, would this structure cause a performance issue in Firebase - since Firebase will have to loop thru all "notes" to determine access before returning the list?



Is there a better way (best practice) to structure the data?



UPDATE



My rules would look something along the lines of:




"rules":
"notes" :
//indexes
".indexOn": ["data/title", "members/author"],
//access
".read": "
auth.uid != null &&
query.orderByChild == 'members/author' && query.equalTo == auth.uid
",
".write": "
auth.uid != null &&
query.orderByChild == 'members/author' && query.equalTo == auth.uid
",
"$noteid":
"data":
"title":
".validate": "newData.isString() && newData.val().length > 0"

,
"members" :
".read" : true,
".write": true,
//validation
".validate": "newData.hasChildren([
'author'
])",
"author" :
".validate": "newData.isString()"



,
"categories":
//The same type of rules as for "notes"
,
"users":
"$userid":
".read": "$userid === auth.uid",
".write": "$userid === auth.uid"






My code would look somethin along the lines of:



const myUid = firebase.auth().currentUser.uid;
const ref = firebase.database().ref('notes');
ref.orderByChild('members/author').equalTo(myUid).on('value', (snapshot) =>
console.log(snapshot.key)
const notesArray =

snapshot.forEach( (childSnapshot) =>
notesArray.push(
id: childSnapshot.key,
data: childSnapshot.val()
);
);

console.log(notesArray);










share|improve this question



















  • 1





    Please show the actual code and security rules that you're asking about. Without that, it is hard to answer any questions about their performance.

    – Frank van Puffelen
    Nov 10 '18 at 15:26











  • Hello Frank, thank you for the reply! I have updated the post to show some conceptual example code. Not sure if the access rules are 100% correct though.

    – Kermit
    Nov 11 '18 at 9:40






  • 1





    That query should work fine on a few hundred thousand child nodes. See stackoverflow.com/questions/28857905/…. But since you can only have one author per node, I'd recommend storing it in a /AuthorNodes/$uid: note1id: true, node2id: true format too.

    – Frank van Puffelen
    Nov 11 '18 at 15:08











  • Hi Frank - Thank you for the prompt reply! I am actually planning on adding more editors alongside author, hence the structure. :) Glad to hear the query should work fine, even with large amounts of data! I have made an update to show editors alongside authors.

    – Kermit
    Nov 11 '18 at 17:40
















1















I am trying to figure out best practices for a Firebase Realtime database structure when securing data. I have read about how to secure the database using Firebase Realtime Database Rules.



For example:
A user adds "notes" and shares those "notes" with other users (members) who can then edit and comment those "notes".
Lets consider a storage structure like the one below:



-categories
-uuid-cat1
-data
title: "my category 1"
-members
author: "uuid-user1"
-notes
-uuid-note1
-data
title: "Hello World!"
categoryId: "uuid-cat1"
-comments
-uuid-comment1
title: "Can you explain?"
author: "uuid-user2"
-uuid-comment2
title: "Certainly!"
author: "uuid-user1"
-members
author: "uuid-user1"
uuid-user2: "uuid-user2" //UPDATE 2 - This is another user with access to the note
-uuid-note2
-data
title: "Hello Universe!"
-categoryIds
uuid-2: "uuid-cat2"
-members
author: "uuid-user2"
-users
-uuid-user1
name: "Jane"
-uuid-user2
name: "Jane"


Users only have access to notes or categories if they are listed as "members/author" or "members/user-id". This is enforced by Firebase Realtime database Rules.



Would this work in on a larger scale?
Let's say we store 200 000 notes.



When requesting to read all "notes" from the database, would this structure cause a performance issue in Firebase - since Firebase will have to loop thru all "notes" to determine access before returning the list?



Is there a better way (best practice) to structure the data?



UPDATE



My rules would look something along the lines of:




"rules":
"notes" :
//indexes
".indexOn": ["data/title", "members/author"],
//access
".read": "
auth.uid != null &&
query.orderByChild == 'members/author' && query.equalTo == auth.uid
",
".write": "
auth.uid != null &&
query.orderByChild == 'members/author' && query.equalTo == auth.uid
",
"$noteid":
"data":
"title":
".validate": "newData.isString() && newData.val().length > 0"

,
"members" :
".read" : true,
".write": true,
//validation
".validate": "newData.hasChildren([
'author'
])",
"author" :
".validate": "newData.isString()"



,
"categories":
//The same type of rules as for "notes"
,
"users":
"$userid":
".read": "$userid === auth.uid",
".write": "$userid === auth.uid"






My code would look somethin along the lines of:



const myUid = firebase.auth().currentUser.uid;
const ref = firebase.database().ref('notes');
ref.orderByChild('members/author').equalTo(myUid).on('value', (snapshot) =>
console.log(snapshot.key)
const notesArray =

snapshot.forEach( (childSnapshot) =>
notesArray.push(
id: childSnapshot.key,
data: childSnapshot.val()
);
);

console.log(notesArray);










share|improve this question



















  • 1





    Please show the actual code and security rules that you're asking about. Without that, it is hard to answer any questions about their performance.

    – Frank van Puffelen
    Nov 10 '18 at 15:26











  • Hello Frank, thank you for the reply! I have updated the post to show some conceptual example code. Not sure if the access rules are 100% correct though.

    – Kermit
    Nov 11 '18 at 9:40






  • 1





    That query should work fine on a few hundred thousand child nodes. See stackoverflow.com/questions/28857905/…. But since you can only have one author per node, I'd recommend storing it in a /AuthorNodes/$uid: note1id: true, node2id: true format too.

    – Frank van Puffelen
    Nov 11 '18 at 15:08











  • Hi Frank - Thank you for the prompt reply! I am actually planning on adding more editors alongside author, hence the structure. :) Glad to hear the query should work fine, even with large amounts of data! I have made an update to show editors alongside authors.

    – Kermit
    Nov 11 '18 at 17:40














1












1








1








I am trying to figure out best practices for a Firebase Realtime database structure when securing data. I have read about how to secure the database using Firebase Realtime Database Rules.



For example:
A user adds "notes" and shares those "notes" with other users (members) who can then edit and comment those "notes".
Lets consider a storage structure like the one below:



-categories
-uuid-cat1
-data
title: "my category 1"
-members
author: "uuid-user1"
-notes
-uuid-note1
-data
title: "Hello World!"
categoryId: "uuid-cat1"
-comments
-uuid-comment1
title: "Can you explain?"
author: "uuid-user2"
-uuid-comment2
title: "Certainly!"
author: "uuid-user1"
-members
author: "uuid-user1"
uuid-user2: "uuid-user2" //UPDATE 2 - This is another user with access to the note
-uuid-note2
-data
title: "Hello Universe!"
-categoryIds
uuid-2: "uuid-cat2"
-members
author: "uuid-user2"
-users
-uuid-user1
name: "Jane"
-uuid-user2
name: "Jane"


Users only have access to notes or categories if they are listed as "members/author" or "members/user-id". This is enforced by Firebase Realtime database Rules.



Would this work in on a larger scale?
Let's say we store 200 000 notes.



When requesting to read all "notes" from the database, would this structure cause a performance issue in Firebase - since Firebase will have to loop thru all "notes" to determine access before returning the list?



Is there a better way (best practice) to structure the data?



UPDATE



My rules would look something along the lines of:




"rules":
"notes" :
//indexes
".indexOn": ["data/title", "members/author"],
//access
".read": "
auth.uid != null &&
query.orderByChild == 'members/author' && query.equalTo == auth.uid
",
".write": "
auth.uid != null &&
query.orderByChild == 'members/author' && query.equalTo == auth.uid
",
"$noteid":
"data":
"title":
".validate": "newData.isString() && newData.val().length > 0"

,
"members" :
".read" : true,
".write": true,
//validation
".validate": "newData.hasChildren([
'author'
])",
"author" :
".validate": "newData.isString()"



,
"categories":
//The same type of rules as for "notes"
,
"users":
"$userid":
".read": "$userid === auth.uid",
".write": "$userid === auth.uid"






My code would look somethin along the lines of:



const myUid = firebase.auth().currentUser.uid;
const ref = firebase.database().ref('notes');
ref.orderByChild('members/author').equalTo(myUid).on('value', (snapshot) =>
console.log(snapshot.key)
const notesArray =

snapshot.forEach( (childSnapshot) =>
notesArray.push(
id: childSnapshot.key,
data: childSnapshot.val()
);
);

console.log(notesArray);










share|improve this question
















I am trying to figure out best practices for a Firebase Realtime database structure when securing data. I have read about how to secure the database using Firebase Realtime Database Rules.



For example:
A user adds "notes" and shares those "notes" with other users (members) who can then edit and comment those "notes".
Lets consider a storage structure like the one below:



-categories
-uuid-cat1
-data
title: "my category 1"
-members
author: "uuid-user1"
-notes
-uuid-note1
-data
title: "Hello World!"
categoryId: "uuid-cat1"
-comments
-uuid-comment1
title: "Can you explain?"
author: "uuid-user2"
-uuid-comment2
title: "Certainly!"
author: "uuid-user1"
-members
author: "uuid-user1"
uuid-user2: "uuid-user2" //UPDATE 2 - This is another user with access to the note
-uuid-note2
-data
title: "Hello Universe!"
-categoryIds
uuid-2: "uuid-cat2"
-members
author: "uuid-user2"
-users
-uuid-user1
name: "Jane"
-uuid-user2
name: "Jane"


Users only have access to notes or categories if they are listed as "members/author" or "members/user-id". This is enforced by Firebase Realtime database Rules.



Would this work in on a larger scale?
Let's say we store 200 000 notes.



When requesting to read all "notes" from the database, would this structure cause a performance issue in Firebase - since Firebase will have to loop thru all "notes" to determine access before returning the list?



Is there a better way (best practice) to structure the data?



UPDATE



My rules would look something along the lines of:




"rules":
"notes" :
//indexes
".indexOn": ["data/title", "members/author"],
//access
".read": "
auth.uid != null &&
query.orderByChild == 'members/author' && query.equalTo == auth.uid
",
".write": "
auth.uid != null &&
query.orderByChild == 'members/author' && query.equalTo == auth.uid
",
"$noteid":
"data":
"title":
".validate": "newData.isString() && newData.val().length > 0"

,
"members" :
".read" : true,
".write": true,
//validation
".validate": "newData.hasChildren([
'author'
])",
"author" :
".validate": "newData.isString()"



,
"categories":
//The same type of rules as for "notes"
,
"users":
"$userid":
".read": "$userid === auth.uid",
".write": "$userid === auth.uid"






My code would look somethin along the lines of:



const myUid = firebase.auth().currentUser.uid;
const ref = firebase.database().ref('notes');
ref.orderByChild('members/author').equalTo(myUid).on('value', (snapshot) =>
console.log(snapshot.key)
const notesArray =

snapshot.forEach( (childSnapshot) =>
notesArray.push(
id: childSnapshot.key,
data: childSnapshot.val()
);
);

console.log(notesArray);







firebase firebase-realtime-database firebase-security-rules






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 11 '18 at 17:43







Kermit

















asked Nov 10 '18 at 12:36









KermitKermit

92114




92114







  • 1





    Please show the actual code and security rules that you're asking about. Without that, it is hard to answer any questions about their performance.

    – Frank van Puffelen
    Nov 10 '18 at 15:26











  • Hello Frank, thank you for the reply! I have updated the post to show some conceptual example code. Not sure if the access rules are 100% correct though.

    – Kermit
    Nov 11 '18 at 9:40






  • 1





    That query should work fine on a few hundred thousand child nodes. See stackoverflow.com/questions/28857905/…. But since you can only have one author per node, I'd recommend storing it in a /AuthorNodes/$uid: note1id: true, node2id: true format too.

    – Frank van Puffelen
    Nov 11 '18 at 15:08











  • Hi Frank - Thank you for the prompt reply! I am actually planning on adding more editors alongside author, hence the structure. :) Glad to hear the query should work fine, even with large amounts of data! I have made an update to show editors alongside authors.

    – Kermit
    Nov 11 '18 at 17:40













  • 1





    Please show the actual code and security rules that you're asking about. Without that, it is hard to answer any questions about their performance.

    – Frank van Puffelen
    Nov 10 '18 at 15:26











  • Hello Frank, thank you for the reply! I have updated the post to show some conceptual example code. Not sure if the access rules are 100% correct though.

    – Kermit
    Nov 11 '18 at 9:40






  • 1





    That query should work fine on a few hundred thousand child nodes. See stackoverflow.com/questions/28857905/…. But since you can only have one author per node, I'd recommend storing it in a /AuthorNodes/$uid: note1id: true, node2id: true format too.

    – Frank van Puffelen
    Nov 11 '18 at 15:08











  • Hi Frank - Thank you for the prompt reply! I am actually planning on adding more editors alongside author, hence the structure. :) Glad to hear the query should work fine, even with large amounts of data! I have made an update to show editors alongside authors.

    – Kermit
    Nov 11 '18 at 17:40








1




1





Please show the actual code and security rules that you're asking about. Without that, it is hard to answer any questions about their performance.

– Frank van Puffelen
Nov 10 '18 at 15:26





Please show the actual code and security rules that you're asking about. Without that, it is hard to answer any questions about their performance.

– Frank van Puffelen
Nov 10 '18 at 15:26













Hello Frank, thank you for the reply! I have updated the post to show some conceptual example code. Not sure if the access rules are 100% correct though.

– Kermit
Nov 11 '18 at 9:40





Hello Frank, thank you for the reply! I have updated the post to show some conceptual example code. Not sure if the access rules are 100% correct though.

– Kermit
Nov 11 '18 at 9:40




1




1





That query should work fine on a few hundred thousand child nodes. See stackoverflow.com/questions/28857905/…. But since you can only have one author per node, I'd recommend storing it in a /AuthorNodes/$uid: note1id: true, node2id: true format too.

– Frank van Puffelen
Nov 11 '18 at 15:08





That query should work fine on a few hundred thousand child nodes. See stackoverflow.com/questions/28857905/…. But since you can only have one author per node, I'd recommend storing it in a /AuthorNodes/$uid: note1id: true, node2id: true format too.

– Frank van Puffelen
Nov 11 '18 at 15:08













Hi Frank - Thank you for the prompt reply! I am actually planning on adding more editors alongside author, hence the structure. :) Glad to hear the query should work fine, even with large amounts of data! I have made an update to show editors alongside authors.

– Kermit
Nov 11 '18 at 17:40






Hi Frank - Thank you for the prompt reply! I am actually planning on adding more editors alongside author, hence the structure. :) Glad to hear the query should work fine, even with large amounts of data! I have made an update to show editors alongside authors.

– Kermit
Nov 11 '18 at 17:40













0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53239019%2ffirebase-realtime-database-structure-best-practice-question%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53239019%2ffirebase-realtime-database-structure-best-practice-question%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Edmonton

Crossroads (UK TV series)