Bookshelf: project status?

[leebenson]

I realise this is an open-source project and the onus is shared on fixes, and I also don't mean to sound rude in any way, but would you mind sharing the status of the project as far motivation for fixes and maintenance from core contributors?

I'm considering using this as our ORM for a client project, and I've run into a couple of situations where parts I'd consider pretty fundamental (such as #1135 and #629) are outstanding months/years later. There are issues labeled 'bug' going back 3 years, and I'm finding myself fumbling round source code because parts of the doc are missing (like this). Again, no judgment, you guys are putting out an awesome lib for free and I appreciate it... but before I build stuff on top of such a core part of my dev, I'd like to get a feel for the motivation behind the project.

Why I'm asking: I came to Bookshelf recently after using Sequelize for years, but feeling the project had hit stagnation and performance was starting to get in the way. Switching to Bookshelf has already fixed performance, but I'm only a couple of days in, and I'm concerned the workarounds I'm implementing will start to mount up and I might wind up spending time hunting down issues that aren't obvious, being unfamiliar with the prohect.

I'm trying to decide whether using 'raw' knex might be a better option. Would love to hear the community's thoughts. Thanks in advance.

[fl0w]

This is an honest opinion by someone who uses bookshelf currently, but not a contributor.

Bookshelf does have some fundamental flaws which I battle with on a daily basis. There's only so much monkey patching I'm comfortable with doing. Not that bookshelf isn't functional, because it really is, just not for our use. I never equate commit history to how viable a project is.

Collections are a continuous headache. An example is the lack of proper events fired which has been addressed but ignored/rejected previously. While existent in Model, a relation becomes a Collection and events (other than Collection.fetched) doesn't fire, and can't even be invoked manually without monkey patching.

The lack of support for composite primary keys (used heavily for our SaaS) is a huge bummer for me. I'm forced to drop down to knex extensively for simple relational SELECTs.

Bookshelf will work fine for most applications, but as with all/most ORM's there's a threshold. I've been personally trying to find time to introduce/switch to objection.js (github) which is very active but also quite young. The repo owners are mature, active, thoughtful and senior developers and it shows. The ORM is quite different compared to both Sequelize and bookshelf.js. I recommend a read through the docs (which are excellent IMO) before giving it a go. The API is still in flux, but the devs are very considerate of semver-versioning with proper multi-version deprecations before removals/updated API.

My two cents which might or might not answer your question.

Edit Edited what browser auto-corrected

[leebenson]

Thanks @fl0w, I appreciate you taking the time to express your experience. You've touched on exactly what my concern is. I've been burned on ORMs before that seem to save on keystrokes but then wind up requiring endless workarounds and monkey patching to either get models to fit, or side-step bugs that never get fixed. Granted, I could fix and submit a PR just like anyone... but I'm choosing a lib to save time, and that could be a rabbit hole that's easier side-stepped just by controlling the SQL that gets fired back manually with knex.

I think I'm probably over-engineering an issue that doesn't exist. Knex is probably as 'high level' as I need. Thanks again for sharing your experience.

[jamesdixon]

@leebenson, I know you've already closed this and @fl0w already gave a great answer, but I felt inclined to chime in.

I'd wholeheartedly agree with what @fl0w has to say. Bookshelf is great, except when it's not. But as you alluded to, designing and maintaining an ORM is no easy task. Especially when you're designing not for one, but for multiple databases. We're using Bookshelf in production and there have been a number of issues that have been difficult to navigate and are still lingering. I too have found myself dropping down to Knex for simple things that should ultimately be trivial with Bookshelf. That said, it's a good piece of software, but may not fit everyone's needs, especially with the lack of activity. With all that said, I'm certainly appreciative of everything that's been done by the Bookshelf team.

Much of what I said is nearly identical to what was said by @fl0w. My real reason for chiming in was more the lack of a core Node ORM, much like Rails has ActiveRecord or Elixir has Ecto. While it's great to have the variety in the Node community, I also believe that an ORM is a complex piece of software that can be greatly helped by a focused, drive community effort. With so many ORM projects scattered throughout the ecosystem, I feel like it's always going to be a battle.

[leebenson]

Good comments, @jamesdixon. Your thoughts echo my own. I'm very appreciative of the hard work the community has put in developing this (free!) software, but have hit its limitations in production way too soon for it to be useful to my particular use case.

I agree that an ORM is a complex piece of software, and I think a lot of projects tackling something of this magnitude tend to stagnate and lose interest over time. It's common for core contributors to lose interest, get busy, move on to other stuff, or for users to move on to the latest thing - all the typical human stuff. This happens too often and you wind up with a project that has 'de facto' status in NPM, yet still has unresolved issues reaching back several years.

Users like me find themselves pinballing from one package to another, trying to find something that doesn't break after 2 days of usage 😄

I also think part of the problem with ORM in general, is the user's expectations. Sometimes it feels like ORM is engineering a problem that doesn't always exist. SQL gives us a rich query language and adding an abstraction on top nearly always takes away from it. There's also a huge performance issue that plights an ORM that is trying to appeal to a broad audience, but has a very slim use case inside of a production project (this is the reason I switched from Sequelize to Bookshelf in the first place, btw - 1.5 second execution times for 15ms of SQL didn't seem a worthwhile trade-off!)

All said and done, moving to knex solved 100% of the problems I experienced fighting with both Sequelize and Bookshelf. It turns out, I didn't need an ORM at all - I just needed a better way to compose 'raw' SQL. Knex solved that, and everything else was easily done in user-land. The idea of being able to abstract away relationships or even underlying DB engines is a bit of a pipedream, IMO... and totally unnecessary. I've moved DB engines exactly zero times, and it's always much faster to plan for necessary relationships/joins ahead of time rather than rely in dynamic functions and query plans provided by an ORM. Hand coding that stuff was a lot faster than trying to use ORM boilerplate and then going down the rabbit hole of patching fundamental issues with the library.

So, my bottom line advice to anyone reading who is fighting with the same problem: Just use knex. It probably does everything you need it to, and anything it doesn't, you'll probably get better performance characteristics writing yourself.