Can I use the same DB for multiple Meteor apps?

Question

Use case: the app I built on app.foo.com, and an instance of telescope on community.foo.com, on separate application servers. The only collection they'd share is users. I would give the same mongo url and oplog url to both apps, and make sure that other than users, collection names did not overlap between the two apps.

Should this work fine? Any performance concerns?

Answer 1

The problem with this is you have to share the collection names.

If you use your databases you're also insured against Telescope suddenly using a collection name that your other app uses on a future version too.

What you can do is only share the users collection if you want.

Server side code (not needed on client)

Accounts.connection = DDP.connect("https://<telescope app url>");

Meteor.users = new Mongo.Collection("users", {
    _preventAutopublish: true,
    connection: Accounts.connection
});

Or more directly (not preferable if you're allowing OAuth logins)

var database = new MongoInternals.RemoteCollectionDriver("<mongo url of telescope app>");
Meteor.users = new Mongo.Collection("users", { _driver: database });

So this app now uses the Telescope app's user's collection.

Answer 2

There would be no problem with this at all. For example it's a common use case to have a user-facing app and an admin app, both using the same db.

Answer 3

This shouldn't be done at the database level:

When any of the two apps evolve, they could break themselves or the other one.

That's the kind of feature that belong in an API layer, or a separate service.

This way you have one user identity service that handles authentication (even cross-domain) and basic user data, and leave each app-specific user information in it's own part of your ecosystem. No risk of meltdown.

I can recommend a few :

• Firebase
• Parse
• Hull.io (disclaimer : I'm a founder)
• Auth0
• LoginRadius

Most of these have client-side libs that you use to handle authentication and just pass back the currently logged-in user's ID to your app.

Some also offer to have one app being the Master, and authenticating users, then telling the service who's logged in, so you can retrieve data from your other app (at hull we call this Bring your own Users)