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

Chaining Multiple Middleware Functions

📖 Context

Up until now, only one middleware function has been passed per route (e.g. createTour for handling POST requests). This lecture covers how to run multiple middleware functions in sequence, for the same route — a technique that will be used constantly throughout the rest of the course.

💡 Why do this?

Similar to the earlier checkID param middleware (which kept ID validation out of the route handlers), it's useful to validate the incoming request body before it ever reaches the createTour handler — keeping that handler focused only on the job of actually creating a tour.

🎯 The Challenge

Build a checkBody middleware that:

  1. ✅ Checks whether req.body contains both a name property and a price property.

  2. ❌ If either is missing, sends back a 400 (Bad Request) response.

  3. ➡️ If both are present, calls next() to proceed to createTour.

🔹 Step 1: Chaining Middleware Syntax

router
  .route('/')
  .get(tourController.getAllTours)
  .post(checkBody, tourController.createTour);

💡 Why this works:

  • 🔗 Multiple functions can simply be passed as additional arguments, separated by commas.

  • ➡️ Express runs them in order: checkBody executes first, and only if it calls next() does createTour run afterward.

  • ⚙️ This is the same chaining mechanism already used implicitly with global middleware — just applied directly at the route level, for a single route.

🔹 Step 2: Implementing checkBody in tourController.js file:

exports.checkBody = (req, res, next) => {
  if (!req.body.name || !req.body.price) {
    return res.status(400).json({
      status: 'fail',
      message: 'Missing name or price'
    });
  }
  next();
};

💡 Why each part works:

  • ✅ !req.body.name || !req.body.price checks if either required field is missing.

  • 🚫 400 Bad Request indicates the client sent invalid data.

  • ⚠️ status: 'fail' is used for client-side errors.

  • 🛑 return prevents the code from continuing after sending the response.

  • ➡️ next() runs only when both name and price are provided.

🔹 Step 3: Wiring It into the Router in tourRoutes.js file:

router
  .route('/')
  .get(tourController.getAllTours)
  .post(tourController.checkBody, tourController.createTour);

🔹 Step 4: Testing

🧪 Test 1 — Missing Price

📤 Sending a POST request with name, duration, and difficulty, but no price →

✅ Response:

  • 🚫 400 Bad Request

  • 💬 "Missing name or price"

This confirms checkBody ran, caught the missing field, and stopped the request from ever reaching createTour.

🧪 Test 2 — With Price Included

📤 Sending the same request but now including a price value →

✅ checkBody's condition is no longer true, so it calls next(), which passes control to createTour

🎉 The tour is created successfully, returning:

  • ✅ 201 Created

💡 Why This Pattern Matters

This same chaining approach can be extended for many other use cases before a resource is created or modified — for example:

  • 🔐 Checking if a user is logged in.

  • 🛡️ Checking if a user has the correct permissions/access rights to perform the action.

  • ✅ Any other validation that shouldn't clutter the main handler.

🎯 Core Principle

Logic unrelated to a handler's core responsibility should live in separate middleware functions, chained before the handler — keeping each handler function narrowly focused on doing exactly one thing (e.g. createTour should only be concerned with creating a tour, not validating input).

✅ Key Takeaway

  • 🔗 A route can have multiple middleware functions, executed in the order they're listed.

  • ➡️ Each middleware must call next() to continue the request.

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

  • ⚙️ Express uses this middleware chaining pattern throughout the app.

  • 🚀 The same approach will be used later for features like authentication and authorization.