4

I have a python/php background and just about to start work on a NodeJS project which is why I have this question. I have worked a bit on frontend JS but this is the first time I will be using JS for some backend work...I fully understand and appreciate the asynchronous nature of JS when it comes to frontend development. But I will be writing a bunch of APIs in NodeJS for the backend. Being new to NodeJS, I cannot help but think: What would be the reason to make asynchronous calls in my backend code? Are there specific scenarios where asynchronous calls will be better on the backend server? The API has to eventually return data in JSON format to the frontend caller....

4
  • 2
    Well, you can make two asynchronous calls at once. You can't make two synchronous calls at once.
    – John Wu
    Oct 21, 2022 at 20:27
  • I thought each HTTP request was served by a single thread in Node, since it ran on JavaScript, and JavaScript is single-threaded. I guess I'm curious about this question, too. Unless await works in Node similar to how await works in C#. Maybe it allows that thread to be suspended while it waits for some external resource, like access to a file system, database or web service? Oct 21, 2022 at 20:42
  • yes nodejs is single threaded, but this single thread can switch between requests via an event loop while waiting on async io result
    – hangyas
    Oct 21, 2022 at 21:12
  • @hangyas node.js has only one thread. Yes, await works similarly in JS to how it works in c#. Oct 21, 2022 at 21:25

2 Answers 2

7

Asynchronous calls are better when your application is io bound opposed to being cpu bound (in case of web applications, almost always). Talking to the database, receiving and sending packets on the network, reading files, etc. is slower than the CPU. Therefore while the program is waiting for the result of an async io call, it can work on processing other requests, resulting in better utilization of resources and responsivenes

It's also important to mention that OS threads are expensive so it's better if one thread can process multiple requests without being blocked. Imagine if fronted js would be synchronous and all tabs would run on their own OS threads: you could still use other tabs while js is blocking on one tab, but it would be a worse overall experience

0

The reason that you would use asynchronous programming on a webserver would be the same reason that it's standard / best practice to do so: to prevent your server from sitting idle and leaving other users waiting for Node to finish what it was doing.

Mainly you're going to want to make sure you're using asynchronous functions to read or write data from / to the file system or a database, as Node can use the time while it's waiting for the operation to complete to service other requests and perform other tasks, and only proceed with the asynchronous function once it has the result.

Basically, Node is designed to handle a lot of requests without a lot of threads, when used properly. It's probably worth having a closer look at the docs to get a better understanding of how it accomplishes this: https://nodejs.org/en/docs/guides/dont-block-the-event-loop

There's also a great article worth reading about measuring how many requests per second you can expect your Node instance to handle (with plenty of YMMV): https://plainenglish.io/blog/how-many-requests-can-handle-a-real-world-nodejs-server-side-application

Not the answer you're looking for? Browse other questions tagged or ask your own question.