Firestore - proper NoSQL structure for user-specific data - firebase

Question

I'm working on an app with Firestore. I use Firebase Authentication for managing users.
The thing is that most of the data in my app would be user-specific. Meaning that users should only have access to their own data.
I've already done research about Firestore security rules, so I know how to handle the security part.
However, I'm wondering how to properly model user-specific data in general. First piece of data I'm adding are categories, that have (for now) 2 properties: name and type.
After some research, I found it's good to create a collection called categories and then a document per-user, each named after the user's ID (UID).
But then, within such a user-specific document, I want to add my categories. One way I figured it out is like on the screenshot below:
So, to describe this approach in a more generic way:
New collection for each data type (e.g. categories)
Inside the collection, separate document named with UID for each user
In each user-specific document, a map with an object's data (e.g. category_1 map with fields name = groceries and type = expense
However, what worries me here is that I need to somehow invent these names of the maps like category_1, category_2 etc... I have a feeling something is wrong in this model, but my strong SQL background doesn't allow me to think that through 😉
Do you have any ideas whether this model is a good one or what problems could it produce later? Maybe you can suggest a better approach for modeling user-specific data in Firestore database?

Answer 1

Is there any limit on how many categories can a single user have? If not then it'll be better to create a collection for categories to avoid hitting 1 MB max document size. If there is a limit and you decide to use a map, I'd recommend creating a map field categories and them as it's children as shown below so if you add any other fields in the document, it'll be much more categorized:
{
categories: {
category_1: {
name: "",
type: ""
},
category_2: {
name: "",
type: ""
}
}
}
However, creating a sub-collection could be better choice as well if each category gets more data in future and you need some queries on categories.
users -> {userId} -> categories -> {categoryId}
(col) (doc) (col) (doc)
As the categories are in a sub-collection you don't need to add userId field in every category document. However you can also create 2 different root collections namely - users and categories:
users -> {userId}
(col) (doc)
categories -> {categoryId}
(col) (doc)
In this case you would have to store userId field to filter between owner of those categories.
#Alex Mamo has perfectly explained difference between using a root level collection and a sub-collection in this post if you need an in-depth explanation: What are the benefits of using a root collection in Firestore vs. a subcollection?
Security rules will be different in both the cases. If you use sub-collections then you can just read user UID from the wildcard like this:
match /users/{userId}/categories/{categoryId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
However, if you use a root level collection, the document ID for each category usually won't have user's UID but the UID will be stored in the document as a field. In that case you would have to read the userId from the document being requested.
match /categories/{categoryId} {
allow read, write: if request.auth != null && request.auth.uid == resource.data.userId;
}
what worries me here is that I need to somehow invent these names of the maps
NoSQL database don't have a schema. You can dynamically add any key as required. Just treat every document as a JSON object.
const newKey = "category_123"
const newValue = {name: "newCatName", type: "expense"}
const userDoc = firebase.firestore().collection("users").doc("userId")
userDoc.update({
[`categories.${newKey}`]: newValue
})
This update operation will create a new child in 'categories' map with the provided values.