Sequelize. The ORM of your nightmares!
You’re making an e-commerce website for a retail company and you managed to convince them to pay you to redesign their buggy, out-dated, 90’s era web page. This is your biggest project yet! You’re not part of a large web-design firm who has the luxury of a consistent customer base. You’re just a freelance developer trying to get by competing against the millions of other developers with the same goal in mind.
Should that bring you down? No. It doesn’t. You’re a developer, you’re a problem-solver, and you stare this challenge down without flinching. The customer you’re meeting with smiles and seems reassured that you’re not going to let them down here. Here we go, time to get started.
First comes the planning. This isn’t a small project and you’ve only got one shot. Got to get it right. A few days later, another meeting with the customer. You’re taking them through a presentation you made, which outlines the new site flow, possible feature-sets, and even a new layout design. The customer seems very pleased with this. They decide to keep moving forward. You’ve got em hooked!
So you’re back home now, you’ve successfully presented your project goals to your customer, and now you’re ready to get started with the database side of things. You choose PostgreSQL. You’re not sure why, but it’s the database program you’ve been using since the beginning. Once that’s done, you look out, and the sun’s coming up through the cracks of your window blinds. It’s tomorrow?
Most of your issues have sprung up from your database ORM. “Go with Sequelize!” they said. “It will be fun!” they said. It wasn’t fun. At some points it was so aggravating, you almost decided to scrap your fancy API wrapper you’ve created and look for different options. So much time was lost because of poor documentation, buggy code, and multiple other issues. “Why did I go with Sequelize…” You mumble under your breath every 5 minutes.
Now, don’t get me wrong. I’m no expert at writing database ORMs (or ODMs, if you’re a mongo fan), but this was the worst experience I have had with any API (front-end or back-end). The documentation wasn’t very helpful either. It explains and defines each method in the API, and gives a couple examples, which is good for any documentation. If you had an issue which was deeper than that of your basic beginner scenarios, then you were SOL bud.
Remember though, creating an ORM (ODM) is not a small undertaking. It requires advanced database knowledge, and right now, the most popular ORM out for NodeJS is filled with bugs and has tons of open issues on GitHub. That’s okay, because it’s open-source, and free-to-use. That’s the sacrifice you have to make for free stuff. But, in most cases, unlike real life, beggars can be choosers!
You don’t have to use an API that you’re uncomfortable using. (Well, unless you’re boss or customer is requiring it.) Just because an API is the most popular, doesn’t mean it’s the most stable, consistent, or polished. You should always be searching for new tools and plugins that can help drive you forward as a developer. Don’t get stuck in one state of mind, keep your options open, it will make you a better developer, and give you an overall better experience.
That being said, everyone has their favorite tools, me included. So use what you most enjoy when you can. You’ll gain experience and solidify you understanding of the tool. Just don’t forget, there are millions of other developers out there creating free, open-source (go help contribute on github, or npm, look for open issues, submit pull requests) tools so that we can focus on creating instead of debugging. They’re making our lives easier, don’t reinvent the wheel unless it’s absolutely necessary.