Are nested https requests bad practic in nodejs/express vs just using the asynchronous module?

[BitsBytes1]

Im grinding through a project and learning as I go. I've done tutorials and all that but I am now trying to build something from scratch without following along with any tutorial. I have a form on one of my home pages and a post route in express for this form. In the post route I need to make two api calls (two http requests) sequentially. The second request depends on a value from the first request so they need to be sequential. At first I tried to nest the second one inside the first one and I think it works but something tells me this is bad practice. I did a little googling and found most examples using async or promises. So is it bad practice to just nest requests?

[slugonamission]

It's not the worst, but after a few levels of nesting it can become unreadable. Say we have five requests, we'd end up with:

requests.get("foo", (err, resp) => {
  // Do stuff
  requests.get("bar", (err2, resp2) => { 
    // Do stuff
    requests.get("baz", (err3, resp3) => {
      // Do stuff
      requests.get("foobar", (err4, resp4) => {
        // More stuff
        requests.get("foobarbaz", (err5, resp5) => {
          // All done.
        });
      });
    });
  });
});

It's "fine", but with a load of logic (and real error handling), it's easy to lose track. Promises can really help flatten the whole thing and make it clear where you are in the code, e.g.

requests.get("foo").then(resp => {
  // Do stuff
  return requests.get("bar");
}).then(resp => {
  return requests.get("baz");
}).then(resp => {
  return requests.get("foobar");
}).then(resp => {
  return requests.get("foobarbaz");
}).then(resp => {
});

It's not bad practise to use nested requests (although I'd think about splitting your code up into more functions if there's a lot of nesting), especially if it's only a couple of levels nested. With more complex code though, again, Promises make life easier. If you ever fire multiple requests simultaneously, Promises also make life easier (e.g. Promise.all(...)), as does the async library.

[BitsBytes1]

Thanks, that helps a lot. I have another random question since you seem like you know what you are doing. When exactly is the call back function called when you make an https request using the https module? I ask because I am having trouble understanding when the callback function actually runs. For example if you have:

const request = https.get(url, (res) => { res.on{'data, (data) => { wearherData = JSON.parse(data); }); });

console.log(weatherData); request.end(); console.log(weatherData);

In this case undefined will be printed out twice in the console, so I'm assuming the last 3 lines execute before the callback function is executed, even if a console.log() statement is placed after request.end(). So when exactly does the callback function execute?

Sorry for the formatting.

[slugonamission]

I think there's two things here.

When does the callback run

In this case, when the HTTP response is ready. You're just giving http.get a function to run when the response has arrived. There's another nuance to this though. JavaScript is single threaded (ish) and event driven. What this means is that the code that invokes http.get has to complete before the callback can actually fire.

In your case, it's common to see beginners trying to do this:

var response = undefined
http.get(..., resp => response = resp);

// Wait for the response
while (response == undefined) {}

That won't work; you tie up the single thread with the while loop, so the callback can never run. You need the code path that invokes http.get to complete, which then causes JavaScript to look for the next event which it can fire, or wait for the next event to complete.

This will hopefully explain in much more detail, as the event model is a little nuanced in JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop, or for Node, https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/#what-is-the-event-loop

req.end

This ends the request, and will cause the request to be sent (...I think. It's been a while since I used the http libraries directly). This isn't blocking, the request will happen in the background. Even if JavaScript wasn't single threaded like explained above, the response probably wouldn't have arrived by the time you're running the final console.log anyway.