I’m building an app that will be accessible by free/paid subscriptions. My instinct is to have each users data in their own private mongoDB collection, these created and named dynamically based on the user sign-up details.
The alternative would be to have a user ID key in each document, with all data in one collection.
It feels safer to keep users data separate, this prevents accidental data leakage, and I assume would make data backup and migration easier, as I would just move the whole collection.
There would be a login/user collection that stores each users data collection name, I would like to use this collection name to then access their private collection.
There will be an additional complication that one user can grant other users access to their collection. (think about sharing in dropbox/onedrive)
TLDR: It’s going to be way, way easier to use a single collection with a userId field.
Having a collection per user is achievable, but will add a lot of complexity to the architecture - to get pub/sub to work “magically” the collection name used in the client and server code need to match. Which, given that the client can never be trusted, leads to the need to add more complex server-side validation, and/or use call and methods - which loses the magic, means you have to do your own optimistic UI … and so on.
If you haven’t already, check out the [Meteor Guide]((http://guide.meteor.com), particularly the sections on pub/sub and security. Hopefully, these will set your mind at rest about using a single collection .
Thanks for the reply, I have read the doc you suggested and indeed the framework appears to robustly manage the userID, this can then be used in the publication with a relevant userID field in the data collection documents I create.
I’m not clear yet on how best to implement a feature where a user can grant read and/or write access to other users by sending an email invitation to them.
This would mean a user could have their own private data and also be able to view data shared by another user using the same login. This would prevent me using the userID as this is managed by the framework.
I would need to hand code (unless there is a package?) a way of grouping users into a ‘organisation’ similar to the way Galaxy user/organisations work.
.