Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rdb – a Node.js ORM with transactions, persistence ignorance and promises

npmjs.com

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Rdb – a Node.js ORM with transactions, persistence ignorance and promises

#21

Post by distracteddev90 »

jermo wrote: post #20
distracteddev90 wrote: post #19

Any chance Rdb plans to support a traditional callback style interface for those of us that prefer to stay away from promises?

I might be missing something but why would you prefer callbacks over promises? I've heard of 'callback hell' but never heard of 'promise hell'.

Both callbacks and promises are fairly simple interfaces for calling a function after some other function has completed.

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/

Re: Rdb – a Node.js ORM with transactions, persistence ignorance and promises

#24

Post by lroal »

distracteddev90 wrote: post #19

Any chance Rdb plans to support a traditional callback style interface for those of us that prefer to stay away from promises?

My plan was to stick to promises only. Unless there are lots of lots of developers that really wants callbacks.

Re: Rdb – a Node.js ORM with transactions, persistence ignorance and promises

#25

Post by mgkimsal »

igl wrote: post #16
aselzer wrote: post #4

Earlier quoted context omitted.

And if you just want a flexible ORM without models, knex ( http://knexjs.org/ ), which bookshelf uses. I found knex + Postgres to be a great combination.

I really really really like Knex. While Mongo claims to be "easy" and "js-native", It's far easier doing complicated queries with Knex on Postgres than on Mongo with the official client. 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.

What would be 'unsecure' about SQL? Not sure I ever heard that argument before.

Re: Rdb – a Node.js ORM with transactions, persistence ignorance and promises

#26

Post by lroal »

sehrope wrote: post #22

Does this allow users to execute custom SQL, in addition to ORM methods, and have it be part of the same transaction?

It is not supported today. But it would't be any problem to implement it. Please create an issue if you want it.

Re: Rdb – a Node.js ORM with transactions, persistence ignorance and promises

#27

Post by [deleted] »

distracteddev90 wrote: post #21
jermo wrote: post #20

Earlier quoted context omitted.

I might be missing something but why would you prefer callbacks over promises? I've heard of 'callback hell' but never heard of 'promise hell'.

Both callbacks and promises are fairly simple interfaces for calling a function after some other function has completed. 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 asy…

[deleted]

Re: Rdb – a Node.js ORM with transactions, persistence ignorance and promises

#28

Post by jermo »

distracteddev90 wrote: post #21
jermo wrote: post #20

Earlier quoted context omitted.

I might be missing something but why would you prefer callbacks over promises? I've heard of 'callback hell' but never heard of 'promise hell'.

Both callbacks and promises are fairly simple interfaces for calling a function after some other function has completed. 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 asy…

Oh ok, was just wondering about your reasons and that clears things up. That's a good read as well. But I think promises give you a way to compose them in a way that callbacks don't. With promises you can call easily call a function when multiple promises are fulfilled.

Re: Rdb – a Node.js ORM with transactions, persistence ignorance and promises

#29

Post by tragic »

distracteddev90 wrote: post #17
bonn1 wrote: post #12

Earlier quoted context omitted.

Good point and I just checked: rdb seems to be for SQL based DBs. 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?

Mongo is great for when you're rapidly developing a product and/or still operating at a small-medium scale. 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…

> Mongo is great for when you're rapidly developing a product and/or still operating at a small-medium scale.

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.

Re: Rdb – a Node.js ORM with transactions, persistence ignorance and promises

#30

Post by distracteddev90 »

jermo wrote: post #28
distracteddev90 wrote: post #21

Earlier quoted context omitted.

Both callbacks and promises are fairly simple interfaces for calling a function after some other function has completed. 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 asy…

Oh ok, was just wondering about your reasons and that clears things up. That's a good read as well. But I think promises give you a way to compose them in a way that callbacks don't. With promises you can call easily call a function when multiple promises are fulfilled.

Actually would argue that Promises are less composable since you're forced to use whatever control flow paradigm the Promise library has provided or add another library to handle control flow.

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.

Post reply on HN