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?
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.
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:
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)
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.
Nice. Thank you @serkandurusoy. Your generosity with deep knoledge & experiance is legendary! And this is just the kind of feedback I was looking for.
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.”
