Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

I'd also add that node.js might not be the right choice for complex backend business logic with lots of service calls because of. Node.js' always-async execution model tends which tends to make things more complicated than need be.

View on HN

I think "always async" is the main advantage of node.

My general (perhaps wrong) impression is that other languages commonly used in backends are moving toward async io, usually through maturing libraries.

It's not that I don't like async (I think it's a defensible choice for JavaScript), but that in my experience backend logic for e.g. e-commerce apps doesn't benefit from using it. Projects which expose services to web frontends are often implemented in an architecture where only one-shot, aggregated service calls (and often times REST-y services) are exposed to Node.js, with the actual business processing and granular service calls being implemented in eg. Java web services in a synchronous programming style. I actually like that architecture because it gives front end devs leaway to define their browser-facing head server backend, rather than enshrine a dogmatic frontend/backend architecture upfront.

It's true that other languages add async models (or emphasize those that they already have), but eg. in the case of Java you're sitting on 20 years of synchronous library and custom code, and it's not clear moving to async is worth it at this pont.

Most services that might be considered "backends" (ie databases, queues, cloud services) end up being in written in languages that can safely use async techniques for I/O and still use real threading or some other method for managing CPU bound problems.

Many of the applications people think of for node.js end up being "glue", much like python, and can live within this constraint for a very long time, where the I/O optimization is a nice benefit.

async / await allows you to choose how async you want your code to be/look, and I for one like to have a choice as opposed to say other languages that don't always have an async option.

C# has this same async await. The only difference - I can choose to use sync workflow by appending .Result to async function, ie `var response = asyncFunction().Result;` .....

Node.js is garbage (well, good for simple crud apps) and so is JS.

But with async/await in JS, you just prepend an `await` and you get the sync workflow.

That being said, I do like how C# handles it more than the way JS has handled it, but both are fantastic.

You can say JS is "garbage" all you want, but it's close to the most popular language on the planet and many many people are writing great things because of it.

"With lots of service calls" describes problems for which async is generally the most performant solution.

It could be, but if the service calls generally depend on the response from the previous service call. Or if you need to rate limit your calls to these services, I think its easier to code it not async

For batches of transactions where each transaction has a service call that depends on the response from a previous service call, async especially outperforms.

Rate limiting is not hard either way, but single-threaded async is slightly easier because your counter is automatically thread safe.

The larger and more complex your system gets the harder it gets to keep it thread-safe. For me this is the big advantage of single-threaded async, and I like node because this single-threaded async is idiomatic in JavaScript.

I strongly disagree. Making many async service calls concurrently and awaiting the result is the text book use case for node.js (well, event based programming in general).

Reply on news.ycombinator.com