View profile

Should You Use an ORM/ODM?

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?
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:
  1. 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.
  2. 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.
  3. 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:
  1. 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.
  2. 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
Other Interesting Reads
bliki: OrmHate
Should I Or Should I Not Use ORM ? | by Mithun Sasidharan | Medium
Did you enjoy this issue?
Mastering JS Weekly

A weekly summary of our tutorials

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue