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.ā
