Node.js ORM evaluation

README.md

We are planning on building a Node.js service. Here's our evaluation of the current ORM landscape:

Last updated: May 2 2016

• Objection.js
  • http://vincit.github.io/objection.js/#introduction
  • Bad: API is Promise based and bulky. This means people can forget to have an error handler due to not being error first
    • http://vincit.github.io/objection.js/#getting-started
  • Good: Uses JSON schema for validation; this means content should be relatively reusable between server/browser
    • http://vincit.github.io/objection.js/#validation
    • http://vincit.github.io/objection.js/#jsonschema
  • Good: Has nice syntax for relationships
    • http://vincit.github.io/objection.js/#polymorphic-associations
  • Good: Built on knex.js which seems to be canonical SQL driver
    • https://github.com/tgriesser/knex
  • Neutral: Recommends using Knex.js' migration tool for migrations
    • https://github.com/Vincit/objection.js/tree/0.4.0
  • Good: Well maintained
    • http://isitmaintained.com/project/Vincit/objection.js
      • Resolution time: 1 day, Open issues: 13%
• Sails
  • https://github.com/balderdashy/sails
  • Not looking for an opinionated MVC, skipping for now
• Waterline, ORM from Sails
  • https://github.com/balderdashy/waterline
  • Bad: Response time takes a while
    • But might be well supported since Sails?
    • http://isitmaintained.com/project/balderdashy/waterline
      • Resolution time: 10 days, Open issues: 2%
• sequelize
  • https://github.com/sequelize/sequelize
  • Good: Syntax is clean and straightforward
    • http://docs.sequelizejs.com/en/latest/docs/getting-started/
    • http://docs.sequelizejs.com/en/latest/docs/querying/
  • Good: Seems to have everything we need (e.g. relationships, validation)
    • http://docs.sequelizejs.com/en/latest/docs/associations/
    • http://docs.sequelizejs.com/en/latest/docs/models-definition/#validations
  • TODO: There might be callback support via nodeify
    • https://github.com/sequelize/sequelize/blob/v3.22.0/lib/promise.js#L44-L45
    • https://www.npmjs.com/package/bluebird-nodeify
  • Good: Well maintained
    • http://isitmaintained.com/project/sequelize/sequelize
      • Resolution time: 1 day, Open issues: 12%
• Bookshelf.js
  • http://bookshelfjs.org/
  • Good: Feels very Backbone.js-esque (e.g. get/set, virtual properties (similar to backbone-relationship))
    • http://bookshelfjs.org/#plugins
  • Good: Supports callbacks
  • Good: Authored by knex.js author
  • Bad: Maintenance isn't great
    • http://isitmaintained.com/project/tgriesser/bookshelf
      • Resolution time: 6 days, Open issues: 28%
• orm2
  • https://github.com/dresende/node-orm2
  • Used it previously, had a terrible experience

Our likely choice is sequelize (possibly with callback bindings via bluebird-nodeify)

@twolfson I randomly found this extensive list. Great work. But I would like to point out that I don't agree about your bad points regarding Objection.js: After working with it quite extensively I can say that the API is extremely well designed and easy to use. I also see the fact that it goes all in with promises a sign that it is future proof, not a hinderance. It's time to say goodbye to callback hell...

I do agree with lehni

I also agree.

Sequelize is also promise based.
Objection.js's support for document storage (arrays and objects in a record) wins it for me. Especially since I'm using Postgres which has jsonb datatypes https://vincit.github.io/objection.js/#documents

Sequelize is absolutely terrible when it comes to trying to do anything with associations. They never work, take wayyyyy more code than to write queries and do all the validation, etc yourself, not very active on slack, and the documentation is dog shit. Save yourself the headache unless you are no tables that are associated to each other.

I agree with the problems on Sequelize, it seems to be a nice library when it comes to documentation but nothing works afterwards when trying to associate.

I'd also concur RE: Sequelize and associations. Doing the simplest things (association via a join table, sort by a column in the join table) is quite difficult, and their documentation is really lacking.

We're considering a move away from Sequelize because of these issues. Objection.js looks promising

Objection is much better architected than Sequelize. Objection is based off of Laravel's Eloquent, which is based off of Rails' ActiveRecord. Both pieces of software are very good. Objection is easily extensible due to its class-based architecture.

Many other users who've had experience in both Sequelize and Objection.js (as I have) are in the same boat: Vincit/objection.js#1069

Should also consider TypeORM.

Also https://github.com/B4nan/mikro-orm

I can't fathom how anyone would say that Objection is a good ORM and Sequelize is a bad ORM. Objection has so many bad practices going for it, it's practically a nightmare. Now there is a disclaimer that I've used Sequelize for much longer than Objection, but just from an API perspective I absolutely loathe Objection. Building it as an extension to Knex.js is just a terrible idea for an ORM.

For those who are having trouble with Sequelize's ORM for associations, what is difficult about:

const { Product, Order } = sequelize.models;
MyModel.findAll({
    include: [{
        model: Order,
        as: 'orders'
    }]
})

Hell, even if you have to do three or four associations deep, it isn't hard because you just add more objects with more includes. Constrast that to Objections, where I have to lay out the join ahead of time. Add in some goofy relationship 'magic' and you have a mess on your hands.

Raw SQL? Sequelize makes it a breeze to execute a raw query and map them to a model. And the queries that Sequelize generate typically are good (except for a few questionable subquery choices, but you can remedy these with a simple subQuery: true option.)

Objection has so many bad practices going for it, it's practically a nightmare.

Please elaborate. I haven't got chance to hear any negative critic about it and that would be really valuable. Only thing I could think of is that it promotes using knex migrations which are not really nice.

@jamespedid Here's the objection equivalent of your example.

const { MyModel } = require('./models/MyModel')

MyModel.query().eager('orders')

here's a four layers deep association fetch

const { MyModel } = require('./models/MyModel')

MyModel.query().eager('orders.someRelation.somethingElse.evenDeeperRelation')

Could you please elaborate what you mean by goofy magic and stuff?

First goofy thing: 'orders' is the name of the SQL table. Why am i littering everywhere in my code with the names of tables? Isn't the ORM supposed to abstract away such details? Even worse, what if I have to change the table in the database? Not unheard of, pretty common as applications tend to age actually. Maybe I'm refactoring and moving schemas. Having implementation details of the database bleed into my code everywhere is a huge problem for me.

Second goofy thing: the awkward DSL of using something like '[why,is,this,an,array,in,a,string]' to eagerly fetch over these entities? Again, incredibly hard to work with in a long-term setting. Having tokenizable, refactorable pieces in a way that is convenient is a big deal. I could use something like [${Why.tableName},${Is.tableName},...], but this is already becoming far more cumbersome than sequelize.

@jamespedid orders is not the SQL table name, it is the relation name defined under MyModel.