Multiple apps or multiple databases?

deployment
1

Hello all,

I created my first web application using Meteor for the school district I work for. It works really well, and now other districts are interested in using it. My problem is trying to decide how to host it for them. Do I create multiple VPS’s for each district? That seems like a management nightmare at scale. Do I somehow create a database for each district and push them to their respective database based on subdomain? Is that even possible?

I want to be able to easily update the app when necessary, but keep everyone’s data safely walled off.

What am I missing, and what is the best practice for my situation? Thanks for any advice you all might have.

Loving Meteor. I can’t believe I was able to create a web app that other people actually want to use.

1 Like
2

Best practice would be to rework your database models so that they allow for multiple districts. In it’s easiest form this would mean adding a collection Districts, each with their own _id. Then in every other collection, including users, have an extra field for the district _id.

So you’d have 1 application running 1 database and the database contains all the data for all districts, but you can query for one specific district. Quick and simple walkthrough:

A user logs in, his user object has a field “district” with the _id of the district he’s part of. Next for all the data he needs, in the publications this _id is passed in the query for district. If you have a collection “Schools” for example, each school would have the _id of the district it’s in. So querying for all the schools in the user’s district would be:

`Meteor.publish("schools", function () {
    var user = Meteor.users.findOne({_id: this.userId});
    return Schools.find({district: user.district});
}`

Same approach for all the other collections. Security-wise this would make it so no user can access data from outside his district if the rest of the application is secure and users can’t edit their own user object for example.

2 Likes
3

OK, I’ll see about going through and refactoring this way. My worry would just be data leakage, which wouldn’t be an issue if it’s all in a silo.

Thanks for the reply and advice!

4

If you set up the publications correctly and handle inserts and updates securely there’s no risk of data leaks between districts, at least not more than the alternative of a separate server and db for each one (as pretty much everything is breachable of course). But setting up multiple servers and db’s wouldn’t be much more secure than the above approach.

If however you absolutely feel you need to separate them, then the only option is to set up a server and db for each district. It’s quite a bit more work of course, but once they’re all set up deploying new versions wouldn’t be that much more work as you could have a single codebase and the only difference between the servers being which db they access, easily doable with an automatic deployment script, probably even with mup.

5

I suggest take a look at this thread: Multitenancy and Meteor

6

My solution, currently, is based on @nlammertyn 's suggestion. All publications are based on a school ID, so if your account has the school ID 78956, you’ll only see students with that ID.

Thanks everyone. I think this will work fine, and allow me to maintain only one codebase.