Wrapping my head around MongoDb, mLab, and Mongoose

1

Hey ya’ll, I’ve got some questions about MongoDb, mLab, and Mongoose that are preventing me from moving forward with my dynamic app projects.

First and foremost, do I need to use Mongoose? What are the benefits of Mongoose? I’m not certain why, but I’ve got this sense that Mongoose is a cop out somehow, is that true or am I just being silly?

Second, when using mLab, how do I connect my database to my applications? I’ve been making a user with (user: admin, password: admin) and using that in my connect statement, but that seems really unsafe and unrealistic. How do I connect to the database dynamically?

Finally, is there a point to using MongoDB locally vs. on mLab? I’ve been connecting straight to mLab via the URI (and admin, admin) but I’m not sure if that’s good practice. If I run MongoDB locally, doesn’t it just turn off once I stop running Mongo?

These questions are a little helter-skelter, but these are the kinds of things that block me during coding-time. Let me know if anything needs to be clarified.

Thanks!

2

So Mongo, when you run it locally, needs you to start/stop it manually. You can start it with a flag that tells it to run as a background process on your computer, but yeah, you actually need to start it up and shut it down.

Advantages to running it locally Vs. hosted: you control it. Disadvantages: you control it. It’s easier to run it hosted, but it’s cheaper for you to run it and you don’t run the risk of the service going down, and you don’t need to be connected to the internet. For small projects, where you can use MLab’s free tier, it’s totally fine if you’re happy with always needing to be connected, it removes a lot of headaches. For anything else, cost will determine whether it’s useful. MLab are doing exactly the same thing as you would do locally, they’re just handling the pain-in-the-ass setup and deployment part - hosted services are great, particularly if your needs mean you can stay in the free tier (once you get past that, cost racks up pretty fast)

admin/admin is fine for development, where you want to access the DB easily, and there’s no issue with you dropping the DB, or corrupting it, or whatever: you want to quickly build/rebuild it, it’s not going to be hacked as it’s just a test, and you don’t want to have to remember a password, or store credentials or whatever. In production you don’t use those credentials because it’s extremely unsafe. But in reality, you’d do exactly the same thing, you’d just be lot more careful about what you pick as the credentials.

Mongoose is a mapper for Mongo (like anything that implements the ActiveRecord pattern or NHibernate or Entity are mappers for relational (SQL) databases). It lets you translate between objects in your code and the objects in your Mongo database, it’s an extra layer that lets you deal with Mongo directly in your chosen language. There are good and bad points about using an abstraction layer, but it isn’t really a cop out. The mapper is often easier to deal with than the the raw domain-specific language used to interact with the database. But it’s an abstraction, and abstractions are often problematic; it allows you to avoid dealing directly with Mongo, that may or may not be something you want. It has a performance cost, but that cost may be so small as to be irrelevant, or the convenience could trump the cost. Or on the other hand, you could have a simple app where it’s just as easy to write the raw queries. Some people will only ever use an object mapper, and never write actual queries. Some people will say that’s stupid, and you shouldn’t use object mappers, that the abstraction is fundamentally the wrong one. It’s context sensitive.

Pretty good overview article: “An Overview of MongoDB & Mongoose” https://medium.com/chingu/an-overview-of-mongodb-mongoose-b980858a8994

Hope that goes some way toward answering, they’re good questions anyway.

2 Likes
3

If you are building your apps on your computer locally, then a local instance of mongo is fine. However, when you want your site to go live, you will want to use mlab as a database as you won’t have your computer running all the time.

Usually you don’t want to put your username and password directly in your connection statement. This is bad:

mongoose.connect('mongo://mlab.uri', { username: 'admin', password: 'admin' }) // <-- BAD

You will want to put this and other sensitive information as environment variables. If you don’t know what this is, they are variables you write in the command that starts your app, for example:

node app.js SECRET_PASSWORD=admin

Obviously, this is impractical, so what most people do is create a file called .env and put their information in there. You can then load this file with the npm module dotenv. Here is an example of how you would do it more correctly:

require('dotenv').load()

mongoose.connect('mongo://mlab.uri',
  {
    username: process.env.USER,
    password: process.env.PASS
  }
)

Your .env file would look like this:

USER=admin
PASS=w54Ke%iB1JxEPRSM5GkaG

You shouldn’t use admin as a password. Use a much more secure one like I did.

You can then gitignore the .env file and you should be lot safer connecting.

1 Like
4

Thanks guys! Those are both very helpful answers. That article, @DanCouper, was very helpful and touched on things that I was wondering about and unsure of how to ask.

@IsaacAbrahamson, thanks for including the stuff about dotenv. I’ve been aware of the .env file, but didn’t really get it’s purpose. I understand its utility now.