loading...

What NodeJS SQL Query Builder/ORM should I use for my Postgres DB, and why?

twitter logo github logo ・1 min read

I am migrating a project from Google Cloud Datastore, and since I am mucking with it anyway I decided I want to move to PostgreSQL because my project better fits a relational model.

The state of Node ORMs seems a bit weak, at least from the last time I had to use Sequelize about a year ago. Documentation was spotty and frustration abounded. The comparisons I can find right now seem to indicate that Sequelize is actually my best option. Can anyone suggest alternatives? Are query builders like Knex better-supported?

twitter logo DISCUSS (6)
markdown guide
 

You should definitely look into TypeORM. It's the strongest Node.js ORM on the market right now, in my opinion.

It's also well-documented and if you use TypeScript, you're in for a treat. Simply because you can define your models using decorators directly in the source code. You'll also get type hinting and strict type checking to boot.

Also, not to toot my own horn or anything, but if you're using GraphQL, check out typeorm-loader, which is something I wrote that implements the functionality of Facebook's dataloader (and more!) on top of TypeORM. It's GraphQL and database-schema aware, so it won't cause any under(or over)-fetching.

 

I've had really nice experience using Objection.js in production with postgre. Relational expresssions are really a killer feature. We have almost 80 tables so you can imagine we use it quite a lot.
We're running a mid-sized CMS with 100k users on AWS.
We experimented also with exposing our objection.js models onto GraphQL using decapi and it works flawlessly!
I personally hope I never have to work on REST api again.

 

There are other O/R mappers besides Sequelize but it is still the biggest as far as I know.

Personally, the more I've worked with O/R mapping the more I've thought the entire approach is a mistake: object-relational impedance mismatch is very real and it always eventually hurts more than the toolkit helps. And in JavaScript especially, where we have anonymous objects, an expressive functional toolkit, and few compunctions about type safety, the Object side of things introduces a lot more overhead than I'm willing to countenance. There's no getting around writing models of some sort in a strongly-typed language like Java, but if you're using JavaScript it's just extra work.

I maintain a data mapper for Node and PostgreSQL: Massive.js. Focusing exclusively on Postgres lets us leverage its full feature set (JSONB, foreign tables, arrays), while the data mapper pattern is much lower-impact than object-relational mapping. Its goal is to be intuitive and unobtrusive -- it introspects your database on startup and builds an API for you, but if you need to do something it doesn't cover it won't get in your way.

 

It's the type hinting/enforcement that I am looking for actually, because I find JS to be a bit too loose. Thanks for the tip! I am looking at KnexJS to just build queries for me without worrying about models (I agree, needless overhead) but I will have to look at Massive!

 

I've never been one for ORMs or Query Builders - to my mind having to learn the huge api of the query building api, and then mapping the complexity and nuance of SQL to it, is simply not worth the cost. That said, resolving raw result rows into meaningful (pure, properly structured) business objects which may have methods and dynamic properties, was of top priority, and so I wrote a library which layers on top database drivers to do so: github.com/craigmichaelmartin/sql-...

 

Personally I dont use ORM. I use libraries like pg to connect to database and use SQL queries themself.You might be interested in this node-postgres.com

Classic DEV Post from Dec 14 '19

Python coders, what are some exercises/activities that help you quickly get better at the basic coding?

Daniel Golant profile image

How well do you know your own code?

Sign up (for free)