Firebase Realtime database structure best practice 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
add a comment |
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
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
add a comment |
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
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
firebase firebase-realtime-database firebase-security-rules
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
add a comment |
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
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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