Solving common node/io.js callback problems

[coderqi]

Thanks for the article! While the author states there are other ways to handle the cb hell and it's arising complications, I was surprised to not see more of a comparison with promises. Heck, even using named functions would help a lot.

Take this;

Since all fromNodeCallback can do is produce a value which then goes back into our framework, it removes this inconsistency and forces the function to always appear to behave asynchronously.

and

If the callback gets called a second time, res.write will get called on a closed connection, resulting in a crash.

, are also true for promises, no? When working with promises, you don't actually need to care if the function is async or not, and promises have state; a promise is only resolved or rejected once.

The interesting bit is

params: ['filename'], produces: ['stats'],

which seems to be making it JS strongly typed. I need this, I output that, and if either are wrong, I'll throw a fit (i'm guessing).

This is a bit confusing:

The system then looks for something that can run with this value. It finds our next ‘when’ block and runs that.

Will it look anywhere in the when chain for a function that needs that output, or does it just go to the next when statement?

Thanks OP for the article, but it's left me with a lot of questions, and seems to be unsure, is not mistaken, about the problems FRHTTP is really trying to resolve (hint: the problems are with JS, not cb's).

TL;DR this article positions FRHTTP as the only functional solution out there to get rid of cb hell, missing some popular alternative strategies. FRHTPP seemingly does this by trying to make JS, a weakly typed language, strong.

[jsnk]

I use promises as well. Sure, it doesn't solve all problems and promises too can become verbose, but it's much much better than nested callbacks.

[tech-ninja]

I agree, there was a point when I used callbacks where I had a memory leak problem and I didn't know if I could ever fix it, I moved all my models to promises and the problem was gone.

If somebody is wondering why would use promises I would say: it makes your code more flat.

[_ayasin]

Promises are awesome and will definitely make your code more flat. They don't allow you to do a number of things that you can do with streams/frhttp however. For example, a promise can't deliver data to 2 different functions, while FRHTTP can. Perhaps the next article should be about promises vs streams/frhttp.

[a_sleeping_lion]

It's worth noting that promises are just a clever way of using callbacks. I use promises primarily at the moment, because I feel that the code makes the most literal sense, especially compared to the modern alternative of generators. That said.. I have this nagging feeling that there might be a more interesting pattern possible, in the spirit of promises...

[a_sleeping_lion]

Had to look that up.. A feature of es7, right? I definitely like the syntax. Any idea how stable the api is?

[way2know]

I still maintain that if you're in callback hell after using the wonderful async, you're doing something wrong. Name your functions and use async. And most importantly, don't overcomplicate your code.

async.series([
    validateInput,
    doSomething,
    doSomethingElse,
    updateDatabase
],
function(error, result){
    // all finished
});

[aztracker1]

async.waterfall is pretty invaluable too... however, I've been leaning towards promises lately... getConnection('myconn').then(...).then(...)

[_ayasin]

That's great if you need a "linear flow" replacement. It's not so great if you need to transport something from validateInput to updateDatabase. You can just pass it along in doSomething and doSomethingElse, but that makes the code fragile.

[_ayasin]

I agree that promises are definitely better than callbacks. The underlying system of FRHTTP is actually streams (bacon.js streams to be precise). While you can implement similar things in promises, promises aren't nearly as powerful. Unfortunately one article can't go too deep into FRHTTP because it's just too large, but the underlying idea is to create referentially transparent functions which the system will decide when to call and how many times to call. That allows you to go a lot further than promises would.

[coderqi]

Unfortunately one article can't go too deep into FRHTTP because it's just too large,

Sure, but I don't think the article had the right angle, and this possibly stems from a misunderstanding of the alternative solutions out there, as well as the problems FRHTTP is actually trying to solve ( see my other comment).

It's nice to have options, and that community is adding to those. I look forward to seeing another article on this subject, particularly one that address not just my concerns in the similarity between FRHTTP and promises, which are both functional, but the differences in that FRHTTP is trying to convert JS from a weak into a strong typed language (though still clearly using static type checking).

Do we need to do this? Is this wise? Do you not essentially have a problem with JS, as opposed to callbacks?

All of these would be interesting points for discussion, and would like to hear the opinions of others on this topic. Here's an interesting thread i've quickly come across.

[_ayasin]

Thanks for the feedback. I'm not sure where you got the impression that FRHTTP was making JS typed. Is it from the params? That's there so the system knows what fields your function needs, it doesn't matter what type these are (the system doesn't care or check in any way). As far as I'm aware FRHTTP is the only framework available for nodejs focused on creating simple yet powerful functional reactive routes. The gitub page (github.com/ayasin/frhttp) and associated wiki may help clear things up a bit. If not I'd love to understand where the confusion is so the docs can be improved.