Should we have a separate collection to store users personal information while login data is in a separate collection?

help
1

Hi,

For our app, we would be collecting some personal information from the user. We are using Meteor.users collection as of now to store the login data.
(Meteor package: okgrow:accounts-ui-react)
We are using Meteor+React.

Should we store all the personal information in a separate collection or add it to the same Meteor.users collection?
I wanted to know the best practice regarding this from security point of view.

Thank you

2

We also use Meteor.users collection to store sensitive user data and it really should not matter if this data is stored in this collection or another collection. More importantly is to follow best security practices overall like using validated methods, server only methods for secrets, and making sure the client can’t update the collection directly.

// Forbid users from making any modifications to their user document
Meteor.users.deny({
  insert: () => true,
  update: () => true,
  remove: () => true
});
1 Like
3

… and not to put sensitive data into the profile property.
Apart from that I would go with storing the date into the profile.

1 Like
4

I prefer to use a profiles collection for additional user data. This way I keep the users collection as clean as possible for Meteor and basic app use and then have full control over the profiles collection. If I had additional analytics dataor something of that sort I would put it into another collection just to keep the data separate as they are different concerns and serve different functions which would then also make it easier to export if needed without much cleanup operations.

5

Thank you @skirunman, @vuhrmeister. I had this question from a performance point of view as well. Is it recommended we still store all the info in Meteor.users collection? Will it not impact the performance of the app if we have a lot of users?

6

@storyteller: Thanks for the answer. I’m sorry I did not understand you. Are you suggesting we store data in different collections and not in Meteor.users collection alone?

7

Yes (though it is obviously up to you).

In short, I’m concerned with separation of concerns and performance. The users collection for me is primarily for Meteor use and maximum I would add to it would be the username (or other info that I’m always displaying). Profile information and other app relevant info I add into the profiles collection so that I have complete control over it and don’t have to worry about changes to Meteor internal stuff (or packages that tie into it) and it would be info that I need only on occasions and hence can easily subscribe to it. Analitics I would also add into another collection. This time so that I don’t have too deep tree structure (which if handled poorly can hinder performance) and can easily separate it from the rest of the app DB for analysis, etc.

8

I’ve actually been dealing with this same problem recently. I’d been saving everything to Meteor.user().profile for two years, and I only just realized that for some clients that resulted in CRAZY amounts of data being saved to the user collection – up to 4mb of data was being loaded every time they tried to log in, because the “profiles” section is automatically subscribed to.

I’m in the process of moving away from that setup and splitting the data-heavy parts into separate collections – it’s definitely a lot of work to do it seamlessly without affecting the user experience, particularly given that I now have more than 100k users. So yes, I’d recommend splitting it up and just keeping the essential account information in the users collection.

2 Likes
9

@jasongrishkoff oh gosh, I think we have two potential case/success studies, blog posts here:

  1. scaling to 100k users (obviously!)
  2. 4mb user profile, what constitutes such large profile data?

I assume not too many Meteor apps - in fact not too many apps - hit either one of these milestones so it would be an amazing service to the community if perhaps you’d be willing to fork this to another thread and start a discussion around your experience so far.

2 Likes
10

  1. For scaling to 100k users, check out my interview on Indiehackers: https://www.indiehackers.com/businesses/submithub

  2. As far as why the profile got so big – the users generate the content on the website, and on each user profile I was saving a small object with key fields from that generated content so I could easily reference them later

I’ll think about starting another thread re: scaling tips I’ve learned :slight_smile:

4 Likes
11

+1 on a new thread on your scaling experience.

And regarding your profile object, I think you should consider a two step move:

  • separate out the profile property into its own collection (you can use publish composite and collection helpers packages to make the transition as seamless as possible)
  • identify larger (probably avatar images) or more repetetive datasets as candidates to go into their own collections (or storage services like in the case of images)
1 Like
12

There should be no performance issues storing user demographic information in the Meteor.users collection on your users, see the Meteor Guide. As mentioned elsewhere in this thread just don’t use the Meteor created profile field as it is published to the client by default.

13

The performance implication would be by pulling up the profile nested property to a top level document therefore enabling publication and reactivity optimizations on it.

You cannot do that with nested properties and based on what you are storing in there, this might have a large impact on app performance.

3 Likes