Apologies in advanced for lack of knowledge in this kind of setting.
Background info that might be important:
So, I’m going to be deploying my app to a wordpress site managed by Dreamhost.
Upon talking to them, the best thing to do in my case is to bundle it to a Node.js program, since they support that (via Passenger).
Unfortunately, they do not offer MongoDB as a managed service, and furthermore the users that I intend to use to store individual user data is stored on a MySQL database, not a Mongo.
They said I can setup a MongoDB server through an
unmanaged service such as; 1) a dedicated server with root access or 2) a
self-managed web server on our cloud service DreamCompute.
My question is this:
Does a Node.js built from a Meteor application require a valid MongoDB? Or if I don’t use it, and find a way to integrate SQL to the Node app, could it just be disregarded as long as I don’t write any code calling MongoDB?
If not, is there a way to host a simple MongoDB that doesn’t require further cost to run aside from what we’re already paying Dreamhost?
Meteor can happily run without MongoDB. Several Meteor webapps created by my business are running purely with Meteor and MySQL.
However, some Meteor packages require it, e.g. Meteor Accounts. If you want to use those, your only choice is to deploy a MongoDB instance locally or remotely.
Otherwise, you will need to either:
Find an alternative Meteor or NPM package that is database-agostic (or natively supports MySQL)
If you think you will change the default Meteor behaviour just because of your hosting limitation then believe me, it isn’t worth your time doing that.
@vlasky did you find a way to use SQL in combination with pub/sub or is it already solved by your package?
I was thinking of proposing an adapter-based solution for the internals, so the internals will never directly be depending on Mongo but on the return values of the adapter (which defaults to an implementation using Mongo) and where the user could provide a custom implementation that would then instead use SQL under the hood.
I think this would easily work out for all parts that simply require document(s) but I am not sure how this would be achieved, if internals depend on cursors or watching the oplog.
@minhna I see your point but the need to use Meteor without Mongo is not a new one and may have also been an issue why people left back in 2016/2017