Running multiple instances of Meteor with separate databases while being able to push updates to each

Iā€™m planning to run a server in the near future, and I was wondering if it had the capabilities of doing some of the features that Iā€™m hoping are available.

Firstly, I would like to know if it is possible to run multiple instances of Meteor on the same server. In addition, in those instances, is it possible to run the exact same code as the original ? And if you run those instances, is it possible to have separate databases that are isolated in that instance? Finally, if I push changes to that server, is it possible to have it change in all of the instances?

If these are possible, how would I do each?

1 Like

You can create a Replica Set with MongoDB, so that the databases will duplicate each other:

Meteor reads the Oplog of the database, so whenever it gets updated, Meteor will see it, and push those updates to the clients etc.

So a user can send an update to database A, and then database B will read the Oplog and duplicate it, and then Meteor B will see it and send it to itā€™s clients, pretty much automatically.

I havenā€™t done this personally though. There could probably be some problems you could run in to that I donā€™t know about.

I am running multiple instances of Meteor on the same server however, each of which has itā€™s own database, on the same MongoDB instance. I use Nginx as a reverse proxy, with different subdomains going to different Meteors.

I have a feeling that you are trying to run a business software for multiple clients and want their databases separate, while keeping versions up to date and in sync, all the while utilizing a single server for its resources and increasing density.

If thatā€™s the case then you should search for keywords like

  • multi tenant
  • multi tenancy

And youā€™ll find some nice resources here on the forum and on stack overflow.

Otherwise, ignore me :slight_smile:

2 Likes

You couldnā€™t have said it better. I wish I would have known the term! Anyways, thanks for the step in the right direction :smile:

1 Like

I was thinking of doing something similar, yet adding in Express for a few long running workers that need to run. I found this post on using Express with Meteor: http://www.mhurwi.com/meteor-with-express/

In my case, I envision my ā€œworker-serviceā€ Meteor backend as a hub-and-spoke style. I will be able to service multiple MongoDBā€™s (multiple-clients), so Iā€™ll need to add an Expressjs ā€œFront-Endā€ to it in order for clients to initiate the service call, then the ā€œworker-serviceā€ will need to access the calling client MongoDB. With this style I donā€™t think I could actually monitor multiple databases for the events to run (maybe itā€™s possible with redis-oplog.

Iā€™d like to point out two important things (possible misconceptions) about the code/approach in that article:

  1. WebApp.connectHandlers is already a connect app and implies app = WebApp.connectHandlers which makes using express kind of redundant (granted, there are some api surface differences)

  2. The await in await Widgets.find() is redundant becuase Widgets is an instance of Meteorā€™s Mongo.Collection and is already synchronous on the server side (due to fibers).

Keeping these two in mind reduces both boilerplate and operational code and simplifies the app.

Iā€™ve recently delivered an api project where the whole app is a rest service (no frontend whatsoever) using Meteor and it was a far better experience compared to setting up a connect/express/whatever project from scratch. Due to widespread use of methods and pub/sub in Meteor, it is often quite easy to overlook the fact that Meteor in essence is a node app with a web server and database (and some sync-style coding utils as well as all modern language features) already built inā€¦

Edit: I should also point out for those who donā€™t know that express and connect are close relatives. express is fully connect api compliant because it used to be based on connect. express is a richer framework for developing restful apis whereas connect is more focused on being an http server framework. although, lots of apps donā€™t use any non-connect apis from express. meaning, connect would be sufficient for most rest api projects.

2 Likes

Nice. Thank you @serkandurusoy. Your generosity with deep knoledge & experiance is legendary! And this is just the kind of feedback I was looking for. :smiley:

Is your advice to just use Meteor Methods as my API surface? If so, I thought Meteor Methods could only be called from ā€œwithin Meteorā€ ā€“ meaning from a DDP connected Meteor client?

Or is your advice to use Meteor HTTP as my API surface? And is this what you used? If so, does it have deficiencies as compared to Express? I thought Meteor HTTP did not implement a RESTful API?

Also, I thought Express was a safe bet because itā€™s been around almost since the beginning of Node and is widely used/accepted as the RESTful API of choice is all.

Edit: Going back now and rereading the article, ā€œOut of the box, Meteor does not offer a RESTful API for non-meteor clients.ā€

1 Like