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)

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.