Express.js Interview Questions

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.

Answer: Express uses an external library called path-to-regexp to compile string route definitions into JavaScript Regular Expression objects.

The Compilation & Matching Mechanics:

• When you register a route (e.g., app.get('/users/:id')), Express compiles it and instantiates a new Layer object.
• This Layer object holds:
  • The path execution function (the handler or middleware).
  • A compiled regular expression (e.g., /^\/users\/([^\/]+?)\/?$/i).
  • An array of keys containing details about the dynamic route parameters (e.g., [{ name: 'id', optional: false, offset: 0 }]).
• Request Resolution: When a request comes in, Express iterates sequentially through its routing stack. For each layer:
  1. It executes the layer's regular expression against req.path.
  2. If it matches, it extracts parameter matches from the capture groups of the regex and populates the req.params object using the stored keys array.
  3. If it doesn't match, it skips the execution callback and proceeds to the next layer in the stack.

---

Answer: By default, Express reads connection metadata directly from the incoming socket (the immediate connection).

• The Problem: When hosted behind Nginx or an Application Load Balancer, the direct client connecting to your Node.js process is the proxy server itself, not the actual user. Consequently, req.ip will return the proxy's local IP (e.g., 127.0.0.1 or 10.0.x.x), and protocol features (like req.secure) will be false because the SSL termination happens at the load balancer.
• The Solution: Enabling trust proxy instructs Express to respect standard forwarding headers:
  • X-Forwarded-For: Contains the chain of client and intermediate proxy IPs. Express will parse this and correctly populate req.ip with the actual user's IP.
  • X-Forwarded-Proto: Indicates whether the user connected via http or https. This ensures req.secure works, which is critical for configuring secure cookies (secure: true).
• Security Risk: Never blindly trust proxies if you are exposed to the raw internet without a proxy frontend, as clients can easily spoof these headers to mask their identity or bypass IP-based rate limits.

---

Answer: To prepare an Express app for production, several security vectors must be locked down:

1. Helmet (helmet): A middleware collection that sets various security-focused HTTP response headers:
   • Content-Security-Policy (CSP): Mitigates Cross-Site Scripting (XSS) and code injection attacks.
   • X-Frame-Options: Prevents Clickjacking by disallowing the site from being rendered inside an <iframe>.
   • Strict-Transport-Security (HSTS): Forces secure (HTTPS) connections.
   • X-Content-Type-Options: Disables MIME type sniffing (prevents executable style/script injections).
2. CORS (Cross-Origin Resource Sharing): Restrict which external domains can read resources from your API. Never leave CORS set to * for authenticated APIs that use cookies or authorization headers.
3. HPP (HTTP Parameter Pollution): Prevents query parameter pollution attacks. If a malicious client passes ?id=123&id=456, Express parses req.query.id as an array ['123', '456']. If your application code expects a string, this can cause runtime crashes or SQL/NoSQL logic injections.
4. JSON Body Limits: Restrict request body size in parser configurations:

   app.use(express.json({ limit: '10kb' })); // Prevents heap exhaustion via massive payloads (DDoS)
   

---

Answer: Rate limiting restricts the number of requests a client can make in a specified window of time.

• The Memory Trap: Using a basic, local, in-memory store in Express is fine for single-instance, local developments. However, in production, applications are typically clustered across CPU cores or scaled horizontally across multiple servers (or Docker containers).
• The Problem: In-memory trackers are isolated to each individual server instance. If a client is hitting a load-balancer, their requests will be distributed across instances, making it easy for them to bypass their limit.
• The Distributed Solution: Use an external, atomic key-value cache like Redis as a centralized rate-limit store.
  • Every server instance queries Redis during incoming requests to increment and check the client's rate-limiting keys.
  • Using Redis scripts or transaction blocks (e.g., MULTI/EXEC or Lua scripts) guarantees that checking and incrementing limits is an atomic operation, preventing race conditions when requests hit multiple nodes simultaneously.

---

Answer: next(err) unwinds the CURRENT router's stack first; finding no 4-arity handler there, Express hops to the parent app's stack — eventually reaching the top-level error middleware. Implications:

• Router-scoped error handlers catch only errors raised within their own mount; mounting order defines reachability (app.use('/api', apiRouter) then later global handler).
• Synchronous throws in handlers ARE routed by Express to error chain; async rejections in Express 4 are NOT — they crash or hang unless wrapped (asyncHandler). Express 5 forwards rejected promises natively — still wrap for uniform enrichment.
• Errors thrown INSIDE error handlers fall back to Express's final default handler (HTML stack trace in dev!) — guard your handler.
• Streaming/response-started errors can't change status codes — destroy socket or log-only; attempting res.status after headers triggers ERR_HTTP_HEADERS_SENT noise.