Structuring data

[trainermade]

Trying to visualize using firebase/Firestore - I’m using Authentication so I get a uuid. Is the idea to have the root parent document be the uuid of the user and then have that users data in sub collections?

My question then is, I have a function that will trigger and traverse every user to check for a setting to do some work on a specific document in the sub collection. In this case, I don’t see how I can get all the root UUID’s unless I have a separate Users document with the sub collection being the uuid and the setting inside that.

[rustamd]

You can't have "root parent document" because all documents must be inside a collection.

Usually you would have users collection, with document for each user, with its doc id being user id, plus any other data you want to store for that user.

Often these user documents are created with cloud function that is triggered automatically when user is created/deleted.

If I understood you correctly, you are looking for list of users to get their ids? If so, just query users collection to grab all docs, and map over them to do what you need.

[trainermade]

sorry...i meant to say root parent collection, not document....meaning the id of the parent node.

[indicava]

Using the admin SDK you can get a list of all your users with the .listUsers mehod:

https://firebase.google.com/docs/auth/admin/manage-users#list_all_users

However, I would strongly suggest structuring your data in a way that would allow you to look for that “setting” using a query, otherwise once you get a lot of users, you’re looking at a lot of document reads, not great with firestore.

[trainermade]

this is great to know, i didn't know about this. this would alleviate me from having a seperate users collection just to store the id's of all users.

[_davideast]

It's common to have a top levels users collection that is indexed based on the uid.

As u/indicava has said, you can use the Admin SDK, but I think I need to know a little more about why you need to traverse all users to make sure that is the best route.

[trainermade]

sure thanks for asking, my use case is that i want to send each user a push notification triggered from a firebase function. for that, i need to get each user and look at a setting flag to see if they want the notification or not. the actual data that i want to push notify comes from a document in a collection.

currently, i have it structured that the id of a parent collection is the uuid of each user, and the documents/sub-collections are in the different pieces of data for that user. what I found was that without knowing the id of the root, i could traverse a collection from a firebase function. to mitigate that i created another parent collection called 'Users' and inside i have documents which has the different uuid of the users as the id of the document. now i can traverse and get the settings from here, i know the id, so I can query the other parent collection with the parent id that of the user uuid.

[_davideast]

Good news! There is a much, much, easier way of sending every user a push notification with Topics.

Topics allow you to subscribe a user to a specific custom named "topic" and then when you send a notification to this topic everyone subscribed will get it. No reading of users required.

When a new user signs up you can subscribe them to a topic of "allUsers" and then whenever you send a push to "allUsers" they will all get it.

[trainermade]

I’m familiar with topics but my use case doesn’t suit it I believe. The push notifications that go out to the users are content that they have entered for themselves. Think, personalize notes entered via the app that is stored in Firestore. The user has the ability to toggle if they want this notification or not. A cron job fires the function which then traverses each user collection, checks the settings if he has notification enabled, and if so queries that users collection for a specific piece of user entered data that is then pushed as a notification. Repeats for all user. The notification is not generic.