asynchronic calls in node.js

Question

I have a basic misunderstanding regarding asynchronic calls using express and middlewares and i would really appreciate some help understanding it.

Suppose we have this code:

var express = require('express')
var cookieParser = require('cookie-parser') 

var app = require('express')
var router = express.Router()

app.use(function timeLog (req, res, next) {
  req.requestTime = Date.now()
  next()
})

app .use(express.json());
app .use(express.urlencoded());
app.use(cookieParser())

router.post('/hello', function (req, res) {
  //write async to file
  res.send('bye')
})

Now, when the client calls this endpoint "hello":

1. are the middlewares which defined in App-level called asynchronicaly? I understood that they do(because they are called "Callbacks" in the documentation... so basically before reaching the router: parsing cookies, parsing json to req.body and adding req.requestTime will run asynchronicaly and then will be routed to '/hello' end point.

2. after routing, is the callback will run asynchronicaly? if yes, then how in this case the request is not left hanging? i see that the response is being terminated inside a body of a callback... how this make any sense? :(

would somebody please explain to me this flow?

I will try to explain how I understood "async calls" through this code above: lets say alot of users trying to get this end point. all these calls added to the call stack, then because of these callbacks are async, then they are moved to event Queue/table and will be handled after the call stack will be "empty". if this is the case, how the first user will ever get a response? the requestTime done async, parsing the json done async and when reaching the router, the callback is done async.... so when the first user will ever get a repsone if all these async calls located inside the event Queue/table and they will be handled only after the callstack is empty? what am i missing here?

Thanks.

Answer 1

The middleware doesn't appear to be asynchronous of its own. In other words, as you said in your comment on another answer, it is not forcing each layer in the expressjs "stack" of middleware/handlers into a separate frame in the JavaScript event queue.

If you trace the next() function in a .use(), there are a couple of setImmediates fairly early on to handle "exit router" or "no more layers," but then you get into a while loop on a stack of handlers. This is happening at around this point in the code.

So if all your middleware was similar to this section, all middleware etc would happen in the same frame within the event queue:

app.use(function(req, res, next){
  console.log('synchronous layer');
  next();
});

Whereas a step like this next one would put the next into a separate frame in the event queue, and potentially allow the process to handle other frames that may be queued up.

app.use(function(req, res, next){
  setImmediate(()=> {
    console.log('setImmediate puts this next() into a separate frame in the event queue');
    next();
  });
});

I can't imagine this would normally be a problem. Most things that would happen in middleware that might take some time (a database call etc) are very likely all going to be happening asynchronously (in a way that puts the next into a new frame in the event queue). But it is something worth considering when you're adding middleware...

Answer 2

All those middleware are using the continuation passing style. So basically they COULD run asynchonous. But they don't have to. It depends on, whether those middlewares are doing some IO. You could take a look into the code to check how the functions behave exactly, but at least, this does not matter. Just keep in mind, that they COULD run asynchronous.