The concurrent are Sequelize (http://sequelizejs.com/) and Bookshelf (http://bookshelfjs.org/), both very mature libraries (look at the Sequelize test suite, it's quite impressing !). Iroal, any comment on the rdb choices against these two big guys ? How can we expect rdb to evolve ?
It was created because we needed a solution with persistence ignorance and that does not have any constraints on foreign key naming, columns, table and so on. By persistence ignorance I mean not needing to call model.save() or pass the connection around everywhere - just edit the properties and commit the transaction.
Everything in rdb is developed TDD outside-in. So it has a lot of unit tests, but not that many integration tests. There are running examples in the demo repo though that could be considered as kind of integration tests.
Choices against sequelize and bookshelf: that is not my mission. If you want a closer integration with express.js, those orms are a better fit than rdb. My main focus on rdb was to keep the API simple and expose as little of the interior as possible - Tell Dont Ask principle.
How to expect rdb to evolve ? -domain logic -aggregate functions -order by -support sqlLite
I found knex + Postgres to be a great combination.
I work on a mongo project and doing aggregate queries is really ugly and painful. Everyone praising mongo probably never made "advanced" queries like that or dismissed SQL as shitty and unsecure without ever using it.
A cohesive set of functions that help you build and execute SQL operations.
Bookshelf has events, which make very easy to wire some kind of persistence ignorance (we implement it in our base Model class).
The people who defend callbacks either don't understand the benefits that promises provide, don't know about async/await or are suffering from stockholm syndrome.
Callbacks do not pass the reversibility test. If everyone had started out with promises and / or async/await, and someone proposed callbacks as a way to deal with this instead, they'd be dismissed as a fool. They're an accident of history and we should forget about them as quickly as possible.
Both interfaces can be abused to give you an ever growing indent and give the appearance of "callback hell"
Both interfaces can be use elegantly to help you reason about your code, make it easy to follow, and handle errors centrally.
Only one is supported natively by node.js and is the standard async interface for 90% of node.js's libraries: Callbacks.
Also, regarding "callback hell", a straw-man argument against callbacks, I highly suggest reading http://callbackhell.com/
I'm currently checking out ORMs for node.
What I found was Bookshelf, Sequelize and Jugglingdb.
I think Rdb needs SQLite support for development purposes and smaller projects.
https://sequelize.readthedocs.org/en/latest/docs/migrations/
- JSON's nature is already very 'object oriented' and I use in code JSON data like it saved—no translation beetween clunky SQL and objects is necessary (if I have a DB which saves JSON natively like Mongo)
- Mongo allows to directly save JSON and stuff like migrations is stuff from the past since tables/collections don't have to be created
- Mongo's Native Driver is low level and at the same time fully sufficient, the syntax is not beautiful and tons of libs sit on top to make it beautiful but I still don't see the need for a real ORM
So, Mongo's Native Driver is your best friend and validations are often a matter of a few lines. Or did I miss anything which is life saving I get from ORMs in a Node/Mongo setup?
But I am wondering who is using SQL based DBs with Node, feels ancient to me, except you build the next datastore for a bank but even then. Also Postgres with its JSON options does not give the feeling, flexibility and speed as Node/Mongo.
I could imagine that the larger part of Node users are working with Mongo, or not?
Promises don't really offer any benefit to program structure overall, generally devs just end up creating long chains of anonymous functions rather than long nests of anonymous functions. Promises actually discourage flat code (and functional programming) for that reason. I understand they seem attractive but become a hack in complex situations.
Not the same thing as in ES6, also that project is totally dead.
> generally devs just end up creating long chains of anonymous functions rather than long nests of anonymous functions
Not true in my experience, also not required at all when using async / await.
> Promises actually discourage flat code (and functional programming) for that reason.
This is really not true, Promises are functional and composable, callbacks are imperative.
> I understand they seem attractive but become a hack in complex situations.
Just no. Callbacks lead to terrible "solutions" like caolan/async, callbacks make refactoring extremely awkward.
Callbacks don't even get to claim better performance, because they require a load of internal hacks in node/io.js to maintain state.
With async/await in the picture, callbacks so totally inferior I can't believe someone would attempt to argue otherwise.
By utilizing callbacks, you are free to use Async.js[0] or Step.js[1] to solve the problem you described. These libraries are great since they give you control over parallel vs series execution of the pre-requisite functions as well as solving more complex control-flow problems such as throttling, etc[2] (See link for more examples).
[0] https://github.com/caolan/async
[1] https://github.com/creationix/step
[2] https://github.com/caolan/async#control-flow
edit: Yes, you can also use similar control-flow libraries with Promises (that follow the specification) to achieve similar results but then the argument for using promises for the sake of control-flow breaks down.
- sequential execution
- parallel execution and wait for all of them to finish
- automated error handling
Couldn't the rest be achieved by simply adding a few (update, delete) methods to the model classes?
Once you start to really scale, you'll start to find a couple parts of MongoDB break-down:
1. MongoDB has no concept of transactions and is not ACID compliant. These short-comings seem innocuous enough at first, but you end up with some crazy potential race conditions that you just end up praying you never face.
2. Distributed MongoDB layers are difficult to implement as well as maintain.
3. MongoDB Replica sets are unpredictable and unreliable in the speed at which they are able to stay up to date and require changes to your code to fully utilize (since you need to ensure you are always reading from a replica when you can, but only ever writing to the master MongoDB instance)
4. At scale, MongoDB will consistently perform worse than Postgres for CRUD-based operations
5. Do you have true relations between documents? Do you ever use Mongoose's convenient `populate()` functionality? If so, you are now making multiple db queries in series when trying to fetch a document(s) from a single collection. This starts to really hurt your query times once you get enough documents/relations in your mongo collections.
I'm sure I'm missing some, but these are some of the areas where MongoDB has fallen down for me in the past.
Yesterday somebody from a node-based consultancy gave a talk at work about microservices, where he remarked in passing that they tend to start projects with mongo, then wait for a schema to kind of 'fall out' of the application as it takes shape, and then switch to postgres or something. Which doesn't seem like an awful idea.
Maybe if you are working with data which inherently has a relational structure using a relational database makes sense. Maybe if you need to ensure transactional consistency, you want to use a data-store which is ACID compliant.
You know: There's no silver hammer. Use the right tool for the right job. Etc etc.
Just a though. A sprinkle of old man's dust onto this new hip generation who thinks JSON solves all the problems in the world.
E-Commerce is one area that isn't `ancient` and that would need the reliability of a traditional ACID compliant DB like Postgresql.