Meteor with multiple Mongo's connection?


I can see same topic but without responses… We want to use multiple mongo connection (at least 5) (permit user to see data for brand A or brand B, like Stripe for ex.). Workflow is :

  1. User choice Brand A
  2. All requests, call, publish, etc… pass trough mongo connection for Brand A
  3. User choice Brand B
  4. Same interfaces than before, but meteor pass trough mongo connection for Brand B

We make some test with RemoteCollectionDriver, but it’s hard to know exactly where to put this segmentation

Is someone already implemant somethings like that ?

One Meteor App can only have one Oplog so you can only publish from one replica set but you can use as many DBs you want, with methods. You just create multiple connections/collections as you wish.

// declare your DB uris
process.env.MONGO_BRAND_B // etc

const _driver = new MongoInternals.RemoteCollectionDriver(process.env.MONGO_BRAND_A, {})
const brandA = new Meteor.Collection('brandA', { _driver })

// etc

// reactivity only for MONGO_URL when with a declared MONGO_OPLOG_URL or with Redis-Oplog:

Can’t we use oplog with RemoteCollectionDriver ? We use oplogToRedis yes

What seems to work better for now, is to declare a global dict on startup, and use it on methods / publish / etc.

But it’s hard to monitor real impact…

I see that it’s possible to passtrough other meteor’s instance to use it as a database layer. Someone experiment that here ?

You’re probably going to want to patch the Mongo.Collection class to have the _collection and _driver be getters. You then use a meteor environment variable to specify the band, then any db calls issued from within a fiber tied to a band would use the relevant db connection. This way your application code doesn’t need to care about different bands beyond selecting them. For the oplog. If the databases exist in different clusters you’d need to use something like redis oplog and use custom channels in publications and updates where you prefix the collection name with a band identifier.

There are other ways of doing it, particularly if you don’t need to care about the meteor.users collection (or other collections defined by third part packages) it will depend on your exact use case.