I already have mongoDB on my mac (OS mavericks) because it comes packaged with Meteor. I'm learning some pure, non-Meteor node.js right now. I'd like to work with mongoDB, but I'm afraid to change any of the configuration I've already got on my machine, as I don't want to screw up the Mongo that comes packaged with Meteor.
Is this something I should be concerned about? How do I protect my other mongo instance?
I assume by the MongoDB that comes with Meteor you mean the MongoDB database Meteor uses internally when you type "meteor" and that resides in .meteor inside your app folder. In that case it's no problem adding a MongoDB installation to the OS, they won't conflict.
In fact, I recommend to separately install MongoDB for different reasons. When you are running a production app it's easier to scale, let multiple apps use the same database etc.
First install MongoDB, for example with Homebrew. Then you just run your app with
MONGO_URL=mongodb://127.0.0.1/<db> meteor
According to mongodb's documentation:
...In many cases running multiple instances of mongod on a single system is not recommended but for testing purposes of course possible.
I don't think that meteor has done intensive configuration changes to mongodb's out-of-the-box configuration (except of course if you've done already configuration amendments for special sharding, Oplog tailing strategies etc.)
Related
Basically I don't want to use an existing mongodb database site like the official mongocloud or whatever-- how can I do what they do, but myself? Do I just include the database folder, along with all of the mongodb executable, in my nodejs folder and call require("child_process").spawn("mongodb.exe", /insert params here/), or is there some kind of way to do this in the mongo module?
And also do I need my own virtual machine to be able to do this or can the following work on a standard heroku nodejs application for example?
Anyone?
Heroku's hosting solution has only ephemeral volumes, so you can't use it for a database. Any files you create are temporary and will be purged on a regular basis.
For example, when your application is idle Heroku will de-provision that resource and clear out any data you've left there.
You can't use Heroku like this, you must use an external database service, or one of their many add-on offerings.
Why there are single web service just for mongodb? Unlike LAMP, I will just install everything on my ec2. So now I'm deploying MEAN stack, should I seperate mongodb and my node server? I'm confused. I don't see any limitation mixing node with mongod under one single instance, I can use tools like mongolab as well.
Ultimately it depends how much load you expect your application to have and whether or not you care about redundancy.
With mongo and node you can install everything on one instance. When you start scaling the first separation is to separate the application from the database. Often its easier to set everything up that way especially if you know you will have the load to require it.
I know that Ruby on Rails has this feature, and in the railstutorial it specifically encourages it. However, I have not found such a thing in nodejs. If I want to run Sqlite3 on my machine so I can have easy to use database access, but postgres in production on Heroku, how would I do this in Nodejs? I can't see to find any tutorials on it.
Thank you!
EDIT: I meant to include Node.JS + Express.
It's possible of course, but be aware that this is probably a bad idea: http://12factor.net/dev-prod-parity
If you don't want to go through the hassle of setting up postgres locally, you could instead use a free postgres plan on Heroku and connect to it from your local machine:
DATABASE_URL=url node server.j
A .env file can make this easier:
https://devcenter.heroku.com/articles/heroku-local#copy-heroku-config-vars-to-your-local-env-file
To switch between production and development Db you use different ports for running you application locally and on Heroku.
As Heroku by default runs the application to port 80 you have a some other port while running your app locally.
This will help you to figure out in run time if your application is running locally or in production and you can switch the Databases accordingly.
You could use something like jugglingdb to do this:
JugglingDB(3) is cross-db ORM for nodejs, providing common interface to access most popular database formats. Currently supported are: mysql, sqlite3, postgres, couchdb, mongodb, redis, neo4j and js-memory-storage (yep, self-written engine for test-usage only). You can add your favorite database adapter, checkout one of the existing adapters to learn how, it's super-easy, I guarantee.
Jugglingdb also works on client-side (using WebService and Memory adapters), which allows to write rich client-side apps talking to server using JSON API.
I personally haven't used it, but having a common API to access all your database instances would make it super simple to use one locally and one in production - you could wire up some location detection without too much trouble as well and have it automatically select the target db depending on the environment it's in.
Somewhat trivial question but I feel it would be crucial to get this answered. My question is about Redis and Node; how to 'run' a Redis db and have Node interact with it.
I plan to use node_redis (https://github.com/mranney/node_redis). I am fairly comfortable saying I understand how to use this module to interact with the Redis db.
My questions if one level higher: how and where is the Redis db 'running'? Do I have to install, create and then run/turn on this db before I am able to use node_redis to manipulate it? Or does the act of requiring node_redis already guarantee that there will be a Redis db to interact with?
Asking because my app will run on a device (not a machine) that I know can execute Node because has Node installed but I cannot install Redis on it (or at least I dont know how to) if Node will not be doing it for me.
WHEW I hope that was not too wordy. TIA!
Niko
Redis is a separate program. You have to download it, install, and run separately. If you'll accept default settings (listen port), node_redis with then connect to it automatically as, by default, redis installation has no passphrase set.
You'd just need to call:
var client = require("redis").createClient();
If your requirements are basic (and chances are they are, since you're running it in a limited environment), you might actually use different key-value store, like nStore which is implemented in JS and uses simple files as a storage. This would not require any other program than node itself.
I have written a Node.JS application that I will have to ship soon, in the form of an RPM (RedHat Package Manager), with everything included (Node, CSS, JS, MongoDB, Node modules, etc.) The total application weights about 60MB compressed, of which about 50MB comes from MongoDB. I would like to reduce the size of the final shipment.
Now, as far as I'm concerned, my Node.JS application only explicitly executes mongod. Looking at the mongodb-linux-i686-2.2.2/bin directory I see about a dozen executables, most of which weight 10.3MB (that's a little curious that so many weight 10.3MB), such as bsondump, mongodump, mongoexport, mongofiles, mongoimport, etc.
Which MongoDB executables are being run under the hood in my "standard" (single database, no sharding, nothing fancy) Node.JS application? Which can I remove for the final shipment?
Only mongod would be required in that scenario.
It might not be legal to create your own distribution of the MongoDB server. See http://www.mongodb.org/about/licensing/ and I would also ask http://www.10gen.com directly for clarification.