Objection.js: Is there anybody who moved to Sequelize after using objection and why?

[TheMisir]

Hello. I want to use objection.js in our new startup. But I don't want to make the wrong choice. What're the positive and negative sides of objection versus sequelize?

[koskimas]

Probably not the best place to ask this. You know, people reading these are probably using objection 😀. You could try reddit?

[TheMisir]

Okay 😀

[koskimas]

We can leave this open. Any answers this may get are probably biased towards objection though, but let's see.

[devinivy]

I can only echo @koskimas: I expect you'll find biased answers here. I also don't know the needs of you, your team, or your application.

Here's my TLDR: based upon experience with both, I would recommend objection over sequelize as it relates to community, maintenance, developer experience, and expressiveness.

I have written or consulted on a variety of applications with different teams and various ORMs. I've additionally written lower-level tools to work with each of sequelize and objection, have been responsible to integrate both ORMs into applications, and have collaborated on db tooling in the node OSS ecosystem.

A couple years ago our development team decided to replace our previous ORM (not sequelize). We did heavy research on existing ORMs including sequelize, objection, and others. We landed on objection and have been _so_ happy with it. When I do find myself on projects that use sequelize, here are some things I miss from objection:

• Sequelize models eagerly require a configured instance of sequelize. This means that either 1. your instance of sequelize is forced to be configured synchronously as a singleton (which I wouldn't recommend) or more likely 2. your models are not static, but instead defined late at runtime, i.e. in a function that receives sequelize as an argument. In objection models are defined statically then can be "bound" later to an instance of knex. This makes it so much simpler to test models, to avoid singletons, to access static parts of the model elsewhere in the application (e.g. referencing validation rules).

• Due to the same "eager" nature of sequelize, it's a little awkward to define relationships between models. It's common to define each model, and then afterwards define the relationships, which leads to the relationships typically not being co-located with the relevant model definition. Objection is "lazier" which allows it to handle this situation differently: relationships are defined directly on the relevant models (statically!) and it works well even when there are circular dependencies. In sequelize this can be worked around, but it requires some boilerplate code that everyone writes slightly differently or doesn't write at all.

• Sequelize is an implementation of the active record pattern, while objection is a fancy query-builder. This is somewhat a matter of preference, but I think it's hard to dispute that objection's closer relationship to SQL makes it more flexible when it comes to taking advantage of DB-specific features and functionality. I'm thinking of support for special db types such as geo or jsonb, falling back to raw query parts, expressing joins and aggregations, etc. Sequelize speaks to all of these topics, but I find it sometimes comes with more limitations, and it takes more time/effort to add this functionality to sequelize. Overall the objection API feels a lot more natural to me, and requires less imagination to use because the semantics of SQL are largely preserved by the library's API.

  • Objection queries are composable. I don't know what else to say, this is hugely awesome and useful.

• Objection has a more close-knit community. By a similar token, it has also kept bugs, issues, feature requests very proactively in check. I realize this is simpler for objection because it hasn't been around for as long as sequelize and has far fewer users. At the same time, I consider them both mature/stable ORMs.

I have a lot of respect for sequelize, its maintainers, and its community. It's been around a long time and has covered a ton of ground, fulfilled a ton of feature requests. Sequelize uses a more standard/familiar pattern, speaks to all the most fundamental SQL features, has more users and probably many more production deployments (P.S. have you seen #1069?), and has a broader ecosystem of related tools (although it's easy to forget that objection is compatible with all tools built for knex). I think that the experience of using one ORM versus the other in a case like this largely comes down to "feel", and the paradigm offered by objection is a more comfortable fit for the teams and applications I work on.

[keepcosmos]

I'm just moving to objection from sequelize.
Most important thing (over philosophy, interface and etc...), Sequelize has too many bugs and PRs are pending.

[yunfan]

i had investigated both library for a little time, and decide to use objection.js
i come from python before

[koskimas]

I'll close this now. People that stopped using objection, probably don't lurk around reading objection issues. This should be asked in Sequalize github, reddit, stackoverflow or anywhere else to get better answers.