Middleware Pattern in Express

1. Execution order and next()

• Middleware functions form a chain of request handlers that execute sequentially in their exact declaration order (app.use(), app.get(path, ...middlewares, handler)).
• A standard route handler accepts (req, res). Middleware functions receive an additional third parameter: (req, res, next).
• Calling next() signals "task completed; advance to the next middleware/handler in the chain." If you forget to call next(), Express halts execution right there, causing the request to hang (the client waits indefinitely because no res.send() or res.json() is ever invoked).
• Verified through hands-on practice: omitting next() inside logMiddleware causes curl to hang with no response returned. Adding next() allows the request to continue normally to the next middleware and then to the handler.
• An authorization check middleware (such as validating an x-api-key header), if invalid, responds with res.status(401).json({...}) and deliberately does not call next(), short-circuiting the request right there without reaching the route handler.

2. Error-handling middleware

• Express provides a specialized middleware variant exclusively for error handling that accepts 4 parameters: (err, req, res, next), unlike regular middleware (2–3 parameters).

app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: 'Something went wrong' });
});

• Express distinguishes between the two types by inspecting fn.length (the declared parameter count of the function) upon registration via app.use(): exactly 4 parameters classifies it as error-handling middleware, while 2–3 parameters registers it as standard middleware.
• Calling next(err) with 1 argument (unlike next() with no arguments) signals an error condition: Express skips all remaining standard middleware and route handlers, jumping directly to the nearest downstream error-handling middleware.

3. Express 4 does not catch errors from async handlers automatically

• Express 4 (widely used in legacy projects) does not automatically catch errors when an async route handler throws or rejects without a try/catch block. In a handler like async (req, res) => { await getOrderFromDB(id); }, if the promise rejects, Express 4 remains completely unaware of the error and fails to forward it to error-handling middleware.
• Consequence: the request hangs (identical to a missing next() bug) because no res.send() is executed. This also serves as a practical example of the unhandled Promise rejection covered in Phase 1, which can crash the entire Node process on modern versions (Node 15+).
• Starting only from Express 5 are errors thrown inside async handlers caught automatically and forwarded to error-handling middleware.

4. Workarounds for Express 4: try/catch + next(err), or the asyncHandler wrapper

• Manual approach per route:

app.get('/orders/:id', async (req, res, next) => {
  try {
    const order = await getOrderFromDB(req.params.id);
    res.json(order);
  } catch (err) {
    next(err);
  }
});

• Repeating try/catch across every route is boilerplate-heavy. A cleaner approach uses an asyncHandler wrapper function that automatically catches rejections and invokes next(err) on your behalf:

function asyncHandler(fn) {
  return (req, res, next) => {
    fn(req, res, next).catch(next);
  };
}

app.get('/orders/:id', asyncHandler(async (req, res) => {
  const order = await getOrderFromDB(req.params.id);
  res.json(order);
}));

• .catch(next) is shorthand for .catch(err => next(err)) when no intermediate processing is required before calling next (passing the function reference directly, known as point-free style). Writing an explicit arrow function is only necessary when adding extra logic (such as logging with console.error before invoking next).