Sequelize: The Module, the Myth, the Legend
Our first experience with Sequelize was a disaster. Weird, cryptic error messages, things breaking left and right, things getting so screwed up it was easier to burn everything down and just restart from scratch — nobody had a good time. No one really managed to get the day’s project completely finished. Then we tried Mongoose, a popular MongoDB ORM, and it was like a breath of fresh air. If you want to change your models, just change them! Error messages that were helpful! All of us latched onto Mongoose and never looked back.
Except… how many of our problems were actually Sequelize’s fault, anyway?
SQL databases are very strict. This can be frustrating during the development process, particularly in agile development, when things are constantly evolving and needing to be tweaked and prodded and rewritten. But this strictness is protective — it means that you can trust the data in your database to be what you expect, which is vital. In our Sequelize debut, we all made a bunch of rookie mistakes — trying to tweak models without migrations, misunderstanding the connection between our model files and the actual database tables, etc. We were learning, and there were growing pains; that’s to be expected.
But that wasn’t Sequelize’s fault.
Furthermore, we were using a PostgreSQL database, which required us to get a postgres server running and set up, which caused a bunch of additional problems. Postgres is powerful, powerful enough to be production-ready, but with great power comes great headaches. It’s not nearly as easy to deal with as MySQL, but MySQL doesn’t scale so well, and it’s good to jump in and get comfortable with the actual technologies that you’ll use in production. Of course, again, there are growing pains.
And again, none of that is Sequelize’s fault.
In the end, there were two major things that were Sequelize’s fault, that bear mentioning in the hopes of drawing attention to the problem and hopefully to fixing them — Sequelize is open source, after all.
The first thing is the cryptic error messages. Frequently the stack trace doesn’t go deep enough to actually direct you to the problem in the code you had written. A lot of the messages are too generic to be helpful. Some of them are helpful once you run into them a few times and begin to recognize the pattern in the problems they indicate, but such trial and error should’t be necessary. This is a legitimate problem that deserves attention.
The second is the fact that Sequelize has, at the time of writing, fairly recently undergone a major version release, meaning that the tried and true “google it” method of problem-solving lead mostly to Stack Overflow answers with outdated syntax and work-arounds that were either no longer necessary or no longer worked… around…
Now that in and of itself is not Sequelize’s fault. But what meant was that the only concrete source of help was Sequelize’s documentation itself. And that documentation is decent, but could definitely stand to be more robust in the area of examples. This issue is relatively minor, overall, but it does exacerbate the cryptic error message problem.
So yes, there are places that could use improvement. However, I think a lot of our struggle has been because Sequelize is a SQL ORM. SQL is strict. SQL requires planning and good, well-thought-out data structures. Using SQL, and Sequelize by extension, requires you to adhere strictly to certain patterns and to be very conscious of your data structure and the changes you make to it. And this is hard. But it’s also rewarding, in the end, when you know you can trust your data.
And in the end, that much is on us, not Sequelize.