Oct 15, 2020

Should You Use an ORM/ODM?

By Mastering JS Weekly • Issue #46 • View online

Object-relational mapping (ORM) and object-document mapping (ODM) libraries are a common point of debate. On one hand, many tutorials start you off working with Mongoose as an ODM for MongoDB, or something like Sequelize for SQL databases. There are also many benefits to using O*M tools even beyond simple tutorials. On the other hand, many experienced Node.js developers are adamant against using ORMs:

Does he have a point?

As usual, the right answer is somewhere in between the two extremes of “you can’t write serious Enterprise-Ready™ software without a battle-tested ORM” and “you can’t write serious Enterprise-Ready™ software unless you hand-write all your own queries.”

Frameworks have strengths, weaknesses, and guide you into certain ways of doing things. Adding a new framework is like deciding whether hire a new person: you should evaluate whether the framework will make your team better or worse.

Here’s some reasons why you might want to use an O*M:

Your team is very junior-heavy. A lot of beginner-friendly tutorials and video courses make heavy use of ORMs and ODMs. The content that your team will be relying on to be productive will often use Mongoose, Sequelize, Bookshelf, etc.
Your team has a strong background in object-oriented programming. If you write a lot of Java and spend a little time in Node, using an O*M will make you feel more at-home in Node.js.
You have a lot of turnover or people switching projects frequently. If you don’t use an O*M, you likely have an alternative database access layer, perhaps one that’s internal to your team or company. Using an O*M makes it more likely that people you’re onboarding are already familiar with your database layer.

On the other hand, here’s some reasons why you might not want to use an O*M:

You or your team are very experienced with your database of choice. In that case, adding an O*M might feel like there’s too many cooks in the kitchen, especially if your team doesn’t have any object-oriented programming purists.
You need every drop of performance you can get. It’s no secret that O*M’s add additional overhead, and that overhead can make your app less performant. However, you should still do a cost-benefit analysis. Of course a faster app is better, all things being equal. But you should carefully consider whether the extra performance will give you better results or not.

Choosing to use an O*M like Mongoose is like adding an extra person to your team who happens to be a huge fan of object-oriented programming. My heuristic is this: if you think you or your team would benefit from hiring a senior-level OOP purist, then an O*M is likely a good choice.

Our new eBook, “Mastering Mongoose” distills 8 years of hard-earned lessons building Mongoose apps at scale into 153 pages. That means you can learn what you need to know to build production-ready full-stack apps with Node.js and MongoDB in a few days. Get your copy!

Most Recent Tutorials

Using Continue in JavaScript forEach() - Mastering JS

The continue keyword doesn’t work with forEach(), but there are ways to skip to the next iteration of a forEach(). Here’s how.

masteringjs.io • Share

How to Break Out of a JavaScript forEach() Loop - Mastering JS

The break keyword doesn’t work with forEach(), but there are several ways to simulate break with forEach(). Here’s how.

masteringjs.io • Share

Websocket Server in Node.js - Mastering JS

The ws package lets you start a websocket server in Node.js. You can also integrate ws with frameworks like Express. Here’s how.

masteringjs.io • Share