8 ms·

BookShelf, Simple ORM for Node

57 points by squiggy22 11y ago

Xantier 11y ago
For end to end usage samples and somewhat comparing to other DBs I can recommend my kitchen-sink project NERD-stack: https://github.com/Xantier/nerd-stack https://github.com/Xantier/nerd-stack
bpicolo 11y ago
My biggest problem with bookshelf is that it automatically grabs column names, so you don't (by default) have any representation in code of what the dang model looks like. Since JS is not typed, this can lead to a lot of having no idea what might be going on unless you wrote the code yourself
- vectorpush 11y ago
  On the other hand, this behavior is quite nice if you want to quickly build something around an existing database and you don't really want to spend time reenumerating the entire schema in code before being able to leverage the ORM.
  - nightski 11y ago
    Meh you essentially are re-enumerating it though, every time you access a field. There is an implicit contract being built up by the code written. I don't find that creating types to make this contract explicit takes much time at all, and there are significant benefits. Unfortunately it simply isn't an option in JS (maybe one could with TypeScript).
    - vectorpush 11y ago
      > I don't find that creating types to make this contract explicit takes much time at all This depends on the complexity of your schema. In my case, I was dealing with a 230 table legacy application where some of the tables had as many as 70 columns. I was tasked with building an ad-hoc administrative tool for the owners so that they could perform a few specific tasks and periodically review some information in the system. I wanted to use an ORM because I didn't want to write a bunch of boilerplate SQL to rig up a tedious but relatively simple internal CRUD app. With that in mind, it certainly didn't make sense to enumerate the details of every column when the alternative (raw SQL) also wouldn't require me to do that. Enumerating explicit column information was unnecessary and certainly would have taken me a lot of time.
      - nightski 11y ago
        Sounds like a poor ORM. I've never had to enumerate the entire schema, just the tables/columns I actually utilize in code.
        vectorpush 11y ago
        Ok, but what I'm saying is that I didn't have to enumerate any schema in this case. I understand the benefits of doing so, but it's sometimes desirable to just get something running rather than spend time mapping your ORM to your schema. If I wrote the SQL directly, I also wouldn't need to enumerate my columns in advance, but bookshelf offers some of the conveniences of an ORM without adding an additional configuration step to the process.
        bpicolo 11y ago
        It takes all of seconds to type out a few field names. =/
        nightski 11y ago
        Not only that, he actually already is doing this when he accesses those fields in code implicitly. He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause). I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order.
        vectorpush 11y ago
        > He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause). haha a string of SQL is not the same thing as a type constrained data structure. > I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order. Thankfully, the client used a database that is capable of enforcing type constraints automatically, so I didn't have to spend time writing business logic to reiterate what the database already knows and strictly enforces, in a language that can't even enforce type constraints anyway. Re-declaring your column names and types in javascript literally does nothing except waste time. You shouldn't be reading through your application code to understand the schema of your database, especially when you're dealing with hundreds of tables.
  - tracker1 11y ago
    Honestly, if I know what the database looks like, I'd rather use babel with string templates for building parameterized queries against the database directly. [1] [2] It seems to me that the layers of ORM (in JS) don't really buy you much more than some simple validation wrappers and a simpler client for SQL queries. After having used a number of ORMs in static environments (mostly C#), I'm much more inclined to prefer a simple SQL client that's easier to make direct SQL queries in than having an ORM in a system that actually complicates things. It'd be one thing if an ORM generated typescript so that you would get auto-complete in your editor/ide, but I don't see much point to this. I'm not a huge fan of typing in JS/TS, but I could at least see the value to some in that case. [1] https://github.com/felixfbecker/node-sql-template-strings https://github.com/felixfbecker/node-sql-template-strings [2] https://github.com/tracker1/mssql-ng https://github.com/tracker1/mssql-ng disclaimer: I wrote mssql-ng and used it for a lot of data migration/manipulation scripts and it was a joy to use with async/await syntax.
    - vectorpush 11y ago
      I actually agree with you and find that writing queries directly gives better performance, is much easier to debug, makes it easier to integrate more advanced database features (like stored procedures or non-standard features like postgres schemas or the jsonb data-type), and avoids the configuration overhead that some ORMs require. In fact, I chose bookshelf precisely because I didn't have to do anything except supply the table name and start CRUDing whereas I'd normally just start writing raw queries in a situation where my goal was to start talking to the database ASAP.
    - mkozlows 11y ago
      I agree with you that ORMs don't add a whole lot of value to Node, but I think there's still value in slightly-higher-level libraries. Like, doing a simple `select whatever from table where x = ? and y = ? and z = ?` is annoying with a string-based query builder when those parameters are optional, sousing something like Knex where you can just pass in a hash of field/value pairs for the criteria for your where clause is a big win.
- jadengore 11y ago
  It's definitely a tradeoff that has led to some problems. However, I think it's important to remember Bookshelf's flexibility, and that the tradeoffs are more language-level than library-level.
steveklabnik 11y ago
I've really only used bookshelf in a pretty basic way, but I've been happy with it.
HNcow 11y ago
Bookshelf isn't bad - but also make sure to check out knex, which Bookshelf is build on top of. Knex is a great Dapper like micro ORM/query builder if you'd just rather do most of your work in SQL.
statenjason 11y ago
Good to see that it's using knex for queries. Many node ORMs dumb every database down to a Mongo-like object hash.
- cwmma 11y ago
  knex is by the same guy, who wrote it expressly for bookshelf
untog 11y ago
I was battling with Sequelize JS for a long time, then discovered Bookshelf. A breath of fresh air, it works so much better. Plus, the underlying library (Knex) is also fantastic for raw queries, migrations, etc.
- ruddct 11y ago
  Out of curiosity, what were you battling with? I've been using them for some time now and have only had good things to say, so curious about your pain points. Ability to plug in custom queries, sensible defaults with options to override everything, and a responsive maintainer have all been great.
- scandox 11y ago
  I'm also curious what your problems were. I'm using it at present and haven't run into anything worrying...yet
  - untog 11y ago
    I didn't have problems as such with Sequelize, it was just a lot more difficult to work with than Bookshelf. And it's been about two years so I don't remember the details, sorry.
- underbluewaters 11y ago
  Same here. Sequelize looks nice on the surface, but I've found its documentation to be atrociously out of date. Bookshelf has less features but works better in practice.
lsdafjklsd 11y ago
I think it's the best ORM for Node. That said it makes me really miss Active Record, which is just... sigh the best.
setheron 11y ago
When I used this back in the day, it was frustrating that the exceptions thrown by BookShelf would be a mismatch of: ValidationErrors, BookShelf errors, database specific errors. It might be a comment on the JavaScript ecosystem but trying to collate all these myriad of exceptions into a single result to show my user was frustrating.
tuananh 11y ago
Can someone help me with this? http://stackoverflow.com/questions/32777559/how-to-join-3-tables-with-bookshelf-in-node-js http://stackoverflow.com/questions/32777559/how-to-join-3-ta...

57 points by squiggy22 11y ago

For end to end usage samples and somewhat comparing to other DBs I can recommend my kitchen-sink project NERD-stack: https://github.com/Xantier/nerd-stack https://github.com/Xantier/nerd-stack

bpicolo 11y ago

My biggest problem with bookshelf is that it automatically grabs column names, so you don't (by default) have any representation in code of what the dang model looks like. Since JS is not typed, this can lead to a lot of having no idea what might be going on unless you wrote the code yourself

vectorpush 11y ago
On the other hand, this behavior is quite nice if you want to quickly build something around an existing database and you don't really want to spend time reenumerating the entire schema in code before being able to leverage the ORM.
- nightski 11y ago
  Meh you essentially are re-enumerating it though, every time you access a field. There is an implicit contract being built up by the code written. I don't find that creating types to make this contract explicit takes much time at all, and there are significant benefits. Unfortunately it simply isn't an option in JS (maybe one could with TypeScript).
  - vectorpush 11y ago
    > I don't find that creating types to make this contract explicit takes much time at all This depends on the complexity of your schema. In my case, I was dealing with a 230 table legacy application where some of the tables had as many as 70 columns. I was tasked with building an ad-hoc administrative tool for the owners so that they could perform a few specific tasks and periodically review some information in the system. I wanted to use an ORM because I didn't want to write a bunch of boilerplate SQL to rig up a tedious but relatively simple internal CRUD app. With that in mind, it certainly didn't make sense to enumerate the details of every column when the alternative (raw SQL) also wouldn't require me to do that. Enumerating explicit column information was unnecessary and certainly would have taken me a lot of time.
    - nightski 11y ago
      Sounds like a poor ORM. I've never had to enumerate the entire schema, just the tables/columns I actually utilize in code.
      - vectorpush 11y ago
        Ok, but what I'm saying is that I didn't have to enumerate any schema in this case. I understand the benefits of doing so, but it's sometimes desirable to just get something running rather than spend time mapping your ORM to your schema. If I wrote the SQL directly, I also wouldn't need to enumerate my columns in advance, but bookshelf offers some of the conveniences of an ORM without adding an additional configuration step to the process.
        bpicolo 11y ago
        It takes all of seconds to type out a few field names. =/
        nightski 11y ago
        Not only that, he actually already is doing this when he accesses those fields in code implicitly. He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause). I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order.
        vectorpush 11y ago
        > He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause). haha a string of SQL is not the same thing as a type constrained data structure. > I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order. Thankfully, the client used a database that is capable of enforcing type constraints automatically, so I didn't have to spend time writing business logic to reiterate what the database already knows and strictly enforces, in a language that can't even enforce type constraints anyway. Re-declaring your column names and types in javascript literally does nothing except waste time. You shouldn't be reading through your application code to understand the schema of your database, especially when you're dealing with hundreds of tables.
- tracker1 11y ago
  Honestly, if I know what the database looks like, I'd rather use babel with string templates for building parameterized queries against the database directly. [1] [2] It seems to me that the layers of ORM (in JS) don't really buy you much more than some simple validation wrappers and a simpler client for SQL queries. After having used a number of ORMs in static environments (mostly C#), I'm much more inclined to prefer a simple SQL client that's easier to make direct SQL queries in than having an ORM in a system that actually complicates things. It'd be one thing if an ORM generated typescript so that you would get auto-complete in your editor/ide, but I don't see much point to this. I'm not a huge fan of typing in JS/TS, but I could at least see the value to some in that case. [1] https://github.com/felixfbecker/node-sql-template-strings https://github.com/felixfbecker/node-sql-template-strings [2] https://github.com/tracker1/mssql-ng https://github.com/tracker1/mssql-ng disclaimer: I wrote mssql-ng and used it for a lot of data migration/manipulation scripts and it was a joy to use with async/await syntax.
  - vectorpush 11y ago
    I actually agree with you and find that writing queries directly gives better performance, is much easier to debug, makes it easier to integrate more advanced database features (like stored procedures or non-standard features like postgres schemas or the jsonb data-type), and avoids the configuration overhead that some ORMs require. In fact, I chose bookshelf precisely because I didn't have to do anything except supply the table name and start CRUDing whereas I'd normally just start writing raw queries in a situation where my goal was to start talking to the database ASAP.
  - mkozlows 11y ago
    I agree with you that ORMs don't add a whole lot of value to Node, but I think there's still value in slightly-higher-level libraries. Like, doing a simple `select whatever from table where x = ? and y = ? and z = ?` is annoying with a string-based query builder when those parameters are optional, sousing something like Knex where you can just pass in a hash of field/value pairs for the criteria for your where clause is a big win.
jadengore 11y ago
It's definitely a tradeoff that has led to some problems. However, I think it's important to remember Bookshelf's flexibility, and that the tradeoffs are more language-level than library-level.

steveklabnik 11y ago

I've really only used bookshelf in a pretty basic way, but I've been happy with it.

HNcow 11y ago

Bookshelf isn't bad - but also make sure to check out knex, which Bookshelf is build on top of. Knex is a great Dapper like micro ORM/query builder if you'd just rather do most of your work in SQL.

statenjason 11y ago

Good to see that it's using knex for queries. Many node ORMs dumb every database down to a Mongo-like object hash.

cwmma 11y ago
knex is by the same guy, who wrote it expressly for bookshelf

untog 11y ago

I was battling with Sequelize JS for a long time, then discovered Bookshelf. A breath of fresh air, it works so much better. Plus, the underlying library (Knex) is also fantastic for raw queries, migrations, etc.

ruddct 11y ago
Out of curiosity, what were you battling with? I've been using them for some time now and have only had good things to say, so curious about your pain points. Ability to plug in custom queries, sensible defaults with options to override everything, and a responsive maintainer have all been great.
scandox 11y ago
I'm also curious what your problems were. I'm using it at present and haven't run into anything worrying...yet
- untog 11y ago
  I didn't have problems as such with Sequelize, it was just a lot more difficult to work with than Bookshelf. And it's been about two years so I don't remember the details, sorry.
underbluewaters 11y ago
Same here. Sequelize looks nice on the surface, but I've found its documentation to be atrociously out of date. Bookshelf has less features but works better in practice.

lsdafjklsd 11y ago

I think it's the best ORM for Node. That said it makes me really miss Active Record, which is just... sigh the best.

setheron 11y ago

When I used this back in the day, it was frustrating that the exceptions thrown by BookShelf would be a mismatch of: ValidationErrors, BookShelf errors, database specific errors. It might be a comment on the JavaScript ecosystem but trying to collate all these myriad of exceptions into a single result to show my user was frustrating.

tuananh 11y ago

Can someone help me with this? http://stackoverflow.com/questions/32777559/how-to-join-3-tables-with-bookshelf-in-node-js http://stackoverflow.com/questions/32777559/how-to-join-3-ta...