
Understanding Node.js Event-Driven Architecture - samerbuna
https://medium.freecodecamp.com/understanding-node-js-event-driven-architecture-223292fcbc2d
======
zipfle
I know I'm in the minority about this, but I still prefer callbacks. In one
common case, you're only doing one or two async things in a given area of the
code, and in that case the async primitive you choose doesn't really matter.
In another common case, you're doing a lot of async things that depend on each
other's outcomes. In that case, I find that it's easier to build a reusable
pattern for handling the specific type of async interaction you have using
callback-based functions, whereas with promises and async/await, you tend to
try to write straight line code that can't be reused and hides the asynchrony
in a way that makes it difficult to debug.

~~~
NathanKP
I'm just too hooked on the async.auto() pattern to give up callbacks. The
ability to break a large flow down into functions and then use a dependency
based structure to automatically execute the flow with the most optimal
concurrency is incredible. And the resulting code is very clean, with each
functional step in the flow living on the same indent level. Refactoring and
adding new steps is very easy as you can just add a new dependency to one of
the existing functions or add a new function that depends on one of the other
functions.

[https://caolan.github.io/async/docs.html#auto](https://caolan.github.io/async/docs.html#auto)

~~~
Matthias247
That looks interesting - as long as you stay in JS land. Once you move into
typescript this kind of system will be impossible to typecheck. Promises and
their compositions will typecheck just naturally compared to that.

~~~
NathanKP
Yep, there is the autoInject which injects previous dependent functions return
values as parameters instead of as properties of a context object, so that may
help some, but it still breaks typechecks.

I wish that promises had a concept similar to this. It's simply too annoying
for me to manually refactor a bunch of Promise.all() calls to manually adjust
the concurrency of the logic flow compared to using the dependency pattern of
async.auto().

And based on what I've seen this is a common problem in both async functions,
generators, and promises. Since it is difficult to properly execute a tree of
functional steps with the maximal concurrency I see code all the time which
just runs async functions or promises in a series instead of taking advantage
of the ability to concurrently execute two branches of the tree at the same
time.

~~~
elithrar
Have you looked at
[http://bluebirdjs.com/docs/api/promise.map.html](http://bluebirdjs.com/docs/api/promise.map.html)
\- which allows you to control the concurrency of Promises easily?

------
partycoder
How can you understand the node event driven architecture without mentioning
the node event loop? You can't.

The event loop is not something you can be abstracted from, it is a core
component of node that you need to be aware of all the time.

If you have long lived code within an event loop tick you will starve the I/O
and everything will start timing out.

Then, freecodecamp (and every other coding camp) do an incredible disservice
to society by telling everyone that ever touched a computer for 5 minutes that
they're "full-stack engineers", a denomination that is in itself very
questionable too.

It's like calling myself a veterinarian because I walked my dog, or calling
myself a chef because I fried an egg. These camps promote a very
oversimplified vision of what it means to be a software engineer.

~~~
sametmax
That's why Python does the contrary and let you use the event loop explicitly.
But then the problem is that you have to deal with it even for simple things.

I think the balance is missing here.

~~~
johnfn
I think the balance is node, which allows an implicit event loop (via
async/await), or an explicit event loop (via using coroutines as standins for
async functions and manually yielding them).

~~~
partycoder
There is "the" event loop in node.
[http://docs.libuv.org/en/v1.x/loop.html](http://docs.libuv.org/en/v1.x/loop.html)

------
xg15
Last time I checked (~ a year ago admittedly), the node.js api itself (e.g.
fs) was still mostly callback-based and had little built-in support for
promises. You either had to resort to 3rd-party wrapper modules or wrap the
calls yourself, resulting in a lot of clutter in your code.

Does anyone know if the situation has changed by now and you can obtain
promises from core functions directly?

~~~
Klathmon
The situation is still that callbacks are king in the node core libraries. But
there is some talk about how to move forward[0], however I don't think there
has been much headway as of the last time I really looked into it about
6-months ago.

That being said, there are some fantastic libraries which you can use as a
drop-in replacement for the core libraries provide a promise based API, but
nothing in core directly.

[0]
[https://github.com/nodejs/NG/issues/25](https://github.com/nodejs/NG/issues/25)

~~~
gotchange
Can you recommend please some of these non CB based libraries?

~~~
karmelapple
supertest-as-promised is pretty great for testing purposes.

~~~
mikewhy
Regular supertest supports promises.

