Express.js Interview Questions — Medium

Answer: Express processes incoming HTTP requests using a linear queue-based pattern called the Middleware Pipeline.

• When a request arrives, Express maps it against active paths. It compiles a sequential list of matching middleware functions.
• The pipeline relies entirely on the invocation of next() to step to the next function.
• Mechanics of next():
  • Calling next() synchronously triggers the execution of the next middleware in line.
  • If you call next('route'), Express skips any remaining middleware functions in the current router stack and immediately jumps back to the main routing cycle.
  • If you call next(err) - meaning you pass any value inside next (except the string 'route') - Express skips all remaining normal middlewares and jumps straight into the Global Error Handling Middleware chain.
  • Anti-pattern Warning: If you call next() but also send a response (e.g., res.send()), execution continues in the subsequent middleware. This often causes the notorious "Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client" crash.

---

Answer: By default, Express intercepts sync runtime exceptions and passes them to its built-in error handler. For custom control, developers define custom error-handling middleware.

Why Exactly Four Arguments? Express checks the length property (arity) of registered middleware functions using JavaScript's reflection features.

• Standard middlewares have an arity of 2 or 3: (req, res) or (req, res, next).
• Error-handling middlewares must have exactly four parameters: (err, req, res, next).
• If you omit the next argument (having only 3 arguments), Express will compile it as a regular middleware and completely fail to route active errors to it.

Standard Template:

app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(err.statusCode || 500).json({
    success: false,
    message: err.message || 'Internal Server Error'
  });
});

---

Answer: express.Router is a mini-express application. It is used to isolate routes, handlers, and middlewares into independent, modular sub-sections of a system.

Benefits:

• Separation of Concerns: Keep code clean. For instance, route logic can be grouped into distinct files: routes/users.js, routes/products.js, and routes/billing.js.
• Router-Level Middleware: You can apply middlewares specifically to a group of routes. For example, applying an API authentication check to all paths mounted on /api/v1 without manually attaching it to each endpoint.

Example mount in primary entry file:

const billingRouter = require('./routes/billing');
app.use('/api/billing', billingRouter); // Isolates billing middlewares

---

Answer:

• In Express 4 (Current Stable): Express does not automatically support resolving rejected promises from standard asynchronous route handlers or middlewares. If a promise rejects inside an async route handler, the server will not pass the error to the global handler; instead, it raises an unhandledRejection event.
  • Workaround: You must explicitly catch the rejection and send it to the next function:

    app.get('/data', async (req, res, next) => {
      try {
        const data = await database.fetch();
        res.json(data);
      } catch (err) {
        next(err); // Crucial step
      }
    });
    

• In Express 5 (Beta/Release Candidate): Express 5 introduces native support for routing rejected promises. If an async route handler rejects or throws an error inside an awaited call, Express automatically calls next(err) behind the scenes.

---

Answer: Battle-tested layout separates bootstrap from wiring:

src/
  app.js          # creates app, mounts middleware/routes (no listen)
  server.js       # listen + graceful shutdown + signal handling
  routes/         # thin routers delegating to controllers
  controllers/    # HTTP layer: validate, call services, shape responses
  services/       # business logic (framework-free, unit-testable)
  repositories/   # data access (knex/prisma/mongoose)
  middlewares/    # auth, rate-limit, error, validation
  config/         # env schema loading/validation
  utils/

Key principles:

• app/server split enables supertest importing app without binding ports, and keeps lifecycle concerns isolated.
• Dependencies injected downward (routes→controllers→services→repos) - services never import Express types, keeping business rules portable/testable.
• Feature-first variant scales better for large domains (modules/users/{routes,controller,service}) - pick one discipline and enforce with lint boundaries.