Understanding the next() Argument

[00:00:00]
>> Speaker 1: Understanding that, basically you only want to call `next()` in my experience The only time you ever call `next()` is in a scenario where your middleware is only checking for something or enhancing the request object, or doing some side effect unrelated to the request, like doing an analytics log or something like that

[00:00:00]
That is the only time you would really call `next()` Other than that, you probably won't be calling `next()` because if you're not doing one of those things, you're probably doing a "Go/No-Go" check, as in either this value is true or false And depending on that, you'll stop the request right now So if there's a Go/No-Go check, then you're either going to do a `res.json()` or `res.send()`, or if it's a go, you'll hit `next()`

[00:00:00]
Those are really the go two scenarios you would be doing this There are obviously more complicated things, but for the most part, it's either: "I'm just a fly on the wall, checking out the request object" - where nothing I do will determine whether I call `next()` or not, I'm just a side effect only inspecting or adding - or "depending on this value, I might call `next()` or not." The scenario of depending on the value is typically about authorization, identification, access control, or even something like "your credit card is expired and your account is past due," so no access

[00:00:00]
Middleware is really good for that Key point: If you are going to return on a network level, you are closing the request, but your code is going to continue to run This is not synonymous with a return statement You could think of it as the return statement for the HTTP request, but it is not the return statement for your code

[00:00:00]
That's still a separate return statement So if there was no return statement here, you're going to have some problems with whatever is about to run next, because you've already responded The best advice is if you ever respond inside a middleware, always hit return after it unless it's the last thing on the line Another important point: If you don't call `next()` in middleware, that's equivalent to not calling a response in a handler - it'll just hang forever

[00:00:00]
Because the system won't know what to do: you're not responding, not calling `next()`, and not throwing an error, so it'll just sit and wait You need to either respond, throw an error, or call `next()` Otherwise, it will hang One of the last things about `next()` is that it does take an optional argument, only one

[00:00:00]
Whatever you pass to `next()` is assumed to be an error That's the only thing you can pass If you call `next()` and pass anything, even just a string that says "yes", Express will assume that's an error When you call `next()` with an error, it tells Express: "Something bad happened Continue, but skip everything supposed to come after this and go to the error handler middleware." If no error handler middleware is registered, it uses the built-in one

[00:00:00]
I cannot emphasize enough how dominant this pattern is I honestly think this pattern single-handedly made Node.js blow up At the time, it was significantly easier to use and understand than contemporaries in other languages If you had to build something in Java or Python before this came out, it was not this simple

[00:00:00]
To this day, frameworks like Fastify or NestJS, even if not built on Express, look at this as inspiration They want to remain compatible with the massive ecosystem of middleware that existed There were tons of Express middleware for everything back in the day This is one of the best developer experiences for servers, and that's why I still use Node.js even though I know Go, Rust, and other languages

[00:00:00]
I will always write a Node.js API until it becomes absolutely impossible, because the experience is so much better I single-handedly give kudos to this pattern.