Hacker News Reader

Comment by twerquie | Hacker News Reader

If your application is largely fetching a bunch of external resources, say from something slow like a database or a web API, mashing them up and returning a response to a client, you need async.

Node has a very beginner-friendly primitive for doing this.

View on HN

> If your application is largely fetching a bunch of external resources, say from something slow like a database or a web API, mashing them up and returning a response to a client, you need async.

Web request maybe, database definitely not. Async means you put a high load on the resource you connect to. In the context of a database that makes absolutely no sense. In fact, it's much more common that if you have an async app that you have a connection pool that gives out limited number of connections. At that point you might just use threads.

Yes.

People in general are really bad at grasping the concept that $programming_paradigm are not all equally suited for a given problem.

Object Oriented, functional, async, strict type system, etc.

I've noticed an almost evangelical nature of people in trying to push their prefered environment on others. Guess what? Node.js is not the answer to everything (and I do 90% of my work in node!). But you know what? Neither is OO, or functional programming. There may be many advantages to your language of choice, but that doesn't mean it's always better.

Fetching resources from many different areas - especially external or unpredictable (3rd party) services - that has async written all over it, and node makes that easy.

I agree that external IO most likely would benefit from async. But, we don't need to turn the entire request-response code flow into async style, just because of one async call. We could break it up into 3 parts: sync code, async code (for external IO), sync code again.

In some code I wrote for a major corporation who will not be named, that's pretty much exactly what was done. We would use a thread pool to spin off a bunch of workers given Future instances to chew on, and then we'd just block waiting for all the results to come back before returning to the client. The thread that handled a request was synchronous to the client, but did all its services requests async and in parallel. Where appropriate we'd also chain things, so one batch of async requests would go out, the results would be gathered and then those results would be used to generate a new batch of async requests, which one again would be gathered and the results used to respond to the client. For those keeping track, this is basically the lazy IO pattern. Not async in the sense of nodejs (which I hate by the way), no callbacks, rather we get a collection of thunks which we can block on evaluating.

Reply on news.ycombinator.com