Reputation: 1633
In tutorials people speak about how the non-blocking, asynchronous features of Node JS mean that the UI remains responsive when performing a slow operation - these are client-side concerns.
However, isn't the normal use case for Node on the server-side - E.g. pulling data from a database and then serving it in an API. In this case is it important at all to be asynchronous? The data is only going to be delivered once all of it is ready anyway so it takes the same amount of time (assuming you're responding to a single http request).
Upvotes: 2
Views: 297
Reputation: 151
driving on the road. and come up to a 4 way stop signs. drive a takes his turn, driver b takes his turn, driver c takes his turn, driver d not paying attention to traffic just setting there. driver, e,f,g in the other 3 sides cursing this driver of not taking his turn, h,i,j folks behind driver D cursing why driver D is not taking his turn at the 4 way stop.
finally driver D takes his turn.
about would be synchronous.
you are out about driving and come up to a 4 way stop light intersection, and there is a left turn lane, a lane to go striaght through, and a right turn lane. and lights for each lane, in all 4 directions.
some times you wait a few moments to turn right, another time you go straight through without waiting (getting green lights) other times you get yellow and red lights. some times you get a left turn green light, and the on coming traffic also gets a left turn green light at same time. while right turn lane folks might get a yellow / yield sign.
it might be stop and go here and there within reason. but this would be more async type of doing. were multi things happen at once.
most larger applications worth their stuff. are intensive database applications. one database request can be rather long. and it may require server to database to server to database to server to database, and a few 100 more times. to get all the data. before server can make a decision of what to send the client.
kinda like cooking a meal, you have various meats and styles of cooking the meat that takes longer time than others, same goes with vegtables, plus you need to deal with plates, silverware, etc... someone might be allergic or only like a certain food cooked a certain way vs others. this is no different than a server processing a request from a client, and getting data from database, from server initial settings, getting templates, getting pictures, and getting ready to package all that data before servering it back to the client.
would you really cook say a turkey, that takes a couple hours, then once it done starting making and cooking some pies that takes another couple hours, and while making pies the turkey gets cold, and when pies get done you start making a single vegetable at time, and only cooking the next vegetable once the previous one is fully done cooking and all dishes have been cleaned, dried and put away. and your plan was to eat everything when it was hot.
cooks multi task errr async, cooking multi things at same time, so at the end everything comes together and within a few minutes of each other, able to serve all the food to the table. not much different than async code. while each task you are doing is sync, all together each piece of the meal becomes async.
Upvotes: 0
Reputation: 225263
In a web application, you may want to run multiple operations at the same time. Node’s standard library accomplishes this concurrency by making those operations asynchronous, i.e. you start them in your code, define what you want them to do when they complete, and continue on without waiting for them.
You also probably want your web application to be able to handle multiple requests at the same time. Node happens to be a single-threaded server, so if you have one Node process, your single thread will have to be free for new work to be able to start handling a new request. If you’re waiting for an asynchronous operation to complete, you’re considered free for work.
This combination means that if you only use synchronous operations to handle a request in Node, you can only handle one request per process. Some web servers are built to work like this, spawning as many new processes (within reason) as are necessary to handle new requests, but Node isn’t. You’re instead intended to make use of its event loop to handle multiple requests concurrently in a single instance.
In tutorials people speak about how the non-blocking, asynchronous features of Node JS mean that the UI remains responsive when performing a slow operation
Unless your UI is using Node (i.e. Node is a client or there is no server involved), this isn’t true. Node isn’t the only form of asynchronous JavaScript, though – take XHR or setTimeout
in browsers, for example. Maybe the tutorials were about those or were just very confused.
Upvotes: 2
Reputation: 30340
Node.js runs in a single thread. Any single thread runtime needs non-blocking i/o to avoid becoming unresponsive.
In a web browser, "unresponsive" means that the user can't interact with the page and the browser can't process regular tasks like requestAnimationFrame
. That's a bad thing, but it only affects one user.
In a web server, unresponsive means that the server cannot respond to any request. If 10 users hit your website at the same time, 9 are blocked whilst 1 waits for the database. That's catastrophic.
Upvotes: 2