Express.js Mastery / Express: Let’s Start Building The Natours API!

Param Middleware

📖 Context

This lecture introduces param middleware — a special type of middleware that only runs when a specific parameter (like id) is present in the URL. In this app, the only relevant route parameter so far is id.

🔹 Step 1: Creating a Basic Param Middleware

router.param('id', (req, res, next, val) => {
  console.log(`Tour id is ${val}`);
  next();
});

💡 Why each part works:

  • 🛣️ router.param() — a special method available on a router, used specifically to define param middleware.

  • 🏷️ First argument ('id') — the name of the parameter this middleware should watch for/run on.

  • 📦 The middleware function still gets req, res, next — but also a fourth argument, conventionally called val, which holds the actual value of that parameter from the URL (e.g. the specific tour ID requested).

  • ⚠️ next() — still required at the end, otherwise the request-response cycle gets stuck and never reaches the actual route handlers further down the stack.

🔹 Step 2: Testing Where This Middleware Runs

  • ❌ GET /api/v1/tours doesn't trigger this middleware because the route has no :id parameter.

  • ✅ It only runs for routes with an :id (e.g., GET /api/v1/tours/5).

  • Requesting a specific tour by ID → ✅ the log appears:

Tour id is 2

  • 👤 Requesting a user by ID → ❌ no log appears, even though the URL also has an id parameter.

💡 Why it Doesn't Run for Users

  • 🛣️ This param middleware was defined only on the tour router.

  • 🧩 Since each router acts like its own mini sub-application, middleware defined on one router only becomes part of that router's middleware stack — it has no effect on a different router (like the user router).

🔄 Request Flow Recap

A request to /tours/:id:

Request
   ⬇
🌍 App-level middleware
   ⬇
🛣️ Tour Router
   ⬇
🆔 Param Middleware (id)
   ⬇
🎮 Route Handler
   ⬇
📤 Response

🔹 Step 3: A Practical Use Case — Removing Repeated ID-Validation Code

❌ The Problem

getTour, updateTour, and deleteTour all contain nearly identical code checking whether the given ID is valid, and returning an "Invalid ID" response if not.

🔁 This is repeated logic sitting in three different places — not good practice.

✅ The Solution

Move that validation logic into a single param middleware that runs automatically before any of these handlers, for any route containing an id.

exports.checkID = (req, res, next, val) => {
  if (req.params.id * 1 > tours.length) {
    return res.status(404).json({
      status: 'fail',
      message: 'Invalid ID'
    });
  }
  next();
};

💡 Why the return Statement Is Critical

  • ❌ Without return, even after sending the 404 response, the function would continue executing and eventually still call next().

  • ➡️ That would move the request into the next middleware, which would then try to send another response.

  • ⚠️ This triggers the classic Express error about not being allowed to set headers after a response has already been sent.

  • ✅ Adding return ensures the function exits immediately after sending the response, so next() is never reached in that case.

🔹 Step 4: Wiring the Middleware into the Tour Router

  • Delete the repeated code from tourController.js file

  • And add console.log(Tour id is ${val}); :

  • Cut the selected part from tourRoutes.js and replace with this code:

router.param('id', tourController.checkID);

  • 🔗 The duplicate ID-checking code is removed from:

    • 📖 getTour

    • ✏️ updateTour

    • 🗑️ deleteTour

  • ✅ Those functions are now free to focus purely on their own job (getting, updating, or deleting a tour) without worrying about validation.

🔹 Step 5: Verifying It Still Works

  • 📖 Request without an ID → ❌ no log, as expected.

  • ✅ Request with a valid ID → the Tour id is X log appears (proving checkID ran), and the actual tour handler still executes normally.

  • ❌ Request with an invalid ID → the middleware catches it and returns the 404 / "Invalid ID" response before the actual route handler ever runs.

  • 🧪 Tested on both GET and PATCH routes with an invalid ID — both correctly return the error from the middleware.

💡 Why This Approach Fits the Express Philosophy

  • 🔄 An alternative would be writing a plain reusable function and manually calling it inside each controller — but that goes against how Express is designed to work.

  • ⚙️ Express favors building a middleware pipeline, where each piece of logic (like ID validation) lives in its own dedicated step in the stack.

✅ Benefit

  • 🎯 Each controller function now only has one responsibility:

    • 📖 getTour → just gets a tour.

    • ✏️ updateTour → just updates a tour.

    • 🗑️ deleteTour → just deletes a tour.

  • 🛡️ None of them need to worry about ID validation.

  • ➕ If a new controller depending on id is added later, it automatically benefits from this validation without any extra code, since the param middleware runs for the whole router.

✅ Key Takeaway

  • router.param() runs middleware only when the specified route parameter exists.

  • The callback receives the parameter value as the fourth argument (val).

  • Param middleware is scoped to its own router.

  • Use return when sending a response to prevent further execution.

  • Centralizing validation in param middleware keeps controllers clean and reusable.