Build a Robust Express + TypeScript Backend with Zero Boilerplate

Building a backend service for a financial application demands precision, reliability, and maintainability. One overlooked try/catch block can bring down an entire server, while loose typing may allow invalid data to corrupt your database. To address these challenges, I designed a production-ready API core using Express, TypeScript, and Zod that eliminates boilerplate, enforces type safety, and ensures consistent error handling.

Eliminate Async Boilerplate with a Higher-Order Function

Writing try/catch blocks in every controller clutters code and increases the risk of human error—omitting error propagation to the global handler is surprisingly common. To solve this, I created a Higher-Order Function (HOF) factory named asyncHandler that wraps asynchronous route handlers. This wrapper automatically catches rejected promises and routes them to a centralized error handler, ensuring no error slips through the cracks.

import { Request, Response, NextFunction, RequestHandler } from 'express';

export const asyncHandler = (fn: RequestHandler): RequestHandler => {
  return (req: Request, res: Response, next: NextFunction) => {
    Promise.resolve(fn(req, res, next)).catch(next);
  };
};

This approach delivers two key benefits:

• Reliability: All async errors are guaranteed to reach the global error handler, preventing silent failures.
• Clarity: Route controllers focus solely on business logic, freeing them from repetitive async control flow logic.

Extend Express’s Native Types with TypeScript Declaration Merging

When working with authentication tokens, request tracing IDs, or validated payloads, developers often resort to unsafe type casting like (req as any).userId. This undermines TypeScript’s type safety entirely. Instead, I used TypeScript’s Declaration Merging feature to extend Express’s built-in Request interface and incorporate custom metadata natively.

export {}; // Ensures this file is treated as a module
declare global {
  namespace Express {
    interface Request {
      auth: {
        userId: number;
        email: string;
      };
      requestId: string;
      validated?: {
        body?: unknown;
        query?: unknown;
        params?: unknown;
      };
    }
  }
}

This solution provides compile-time type safety without adding runtime overhead, as .d.ts files generate no JavaScript after compilation.

Validate Inputs Programmatically with Zod Middleware Factories

Financial APIs handle sensitive data—transaction details, user updates, and thresholds—making input validation critical. Embedding validation logic inside route controllers violates the Separation of Concerns principle. To streamline this, I built a generic middleware factory named validate that leverages Zod to dynamically validate incoming data based on schema definitions.

import { NextFunction, Request, Response, RequestHandler } from "express";
import { z } from "zod";
import AppError from "../utils/AppError";

type Source = 'params' | 'body' | 'query';

export default function validate<T extends z.ZodType>(
  schema: T,

): RequestHandler {
  return (req: Request, _res: Response, next: NextFunction) => {
    const parsedValue = schema.safeParse(req[source]);
    if (!parsedValue.success) {
      return next(
        new AppError(
          parsedValue.error.issues[0]?.message ?? "Validation Error",
          400
        )
      );
    }
    if (!req.validated) {
      req.validated = {};
    }
    req.validated[source] = parsedValue.data;
    next();
  };
}

This middleware dynamically validates data from the request body, query, or URL parameters, appends the validated data to the augmented req.validated object, and blocks malformed requests automatically. The result is clean, declarative route handling where data integrity is enforced upstream.

For example, a transaction update route becomes remarkably concise:

router.patch(
  '/transactions/:id',
  validate(transactionIdSchema, 'params'),
  validate(updateTransactionSchema, 'body'),
  asyncHandler(updateTransaction)
);

Centralize Errors with a Global Error Handler

Rather than scattering error responses like return res.status(400).json(...) across controllers, I implemented a dedicated global error middleware. This middleware inspects error instances in real time, categorizes them correctly, and maps them to appropriate HTTP status codes.

import { Request, Response, NextFunction } from 'express';
import { ZodError } from 'zod';
import AppError from '../utils/AppError';

const errorMiddleware = (
  err: unknown,
  _req: Request,
  res: Response,
  _next: NextFunction
): void => {
  console.error(err);
  let statusCode = 500;
  let message = 'Internal Server Error';

  if (err instanceof AppError) {
    statusCode = err.statusCode;
    message = err.message;
  } else if (err instanceof ZodError) {
    statusCode = 400;
    message = err.issues[0]?.message ?? 'Validation Error';
  } else if (err instanceof Error) {
    message = err.message;
  }

  res.status(statusCode).json({
    success: false,
    message,
  });
};

export default errorMiddleware;

This approach simplifies error management, improves consistency, and ensures predictable responses for both operational and validation errors.

Orchestrate Middleware in the Right Order for Maximum Stability

Middleware registration order in Express determines execution order. Misplaced logging or error middleware can lead to silent failures or crashes. To avoid these pitfalls, I structured the application entry point (app.ts) to ensure security, performance, and observability layers execute in the correct sequence.

import express from 'express';
import helmet from 'helmet';
import cors from 'cors';
import compression from 'compression';
import cookieParser from 'cookie-parser';
import swaggerUi from 'swagger-ui-express';
import healthRoutes from './routes/health.routes';
import authRoutes from './routes/auth.routes';
import transactionRoutes from './routes/transaction.routes';
import analyticsRoutes from './routes/analytics.routes';
import errorMiddleware from './middleware/error.middleware';

const app = express();

app.use(express.json());
app.use(helmet());
app.use(cors());
app.use(compression());
app.use(cookieParser());

app.use('/docs', swaggerUi.serve, swaggerUi.setup(...));
app.use('/health', healthRoutes);
app.use('/auth', authRoutes);
app.use('/transactions', transactionRoutes);
app.use('/analytics', analyticsRoutes);

app.use(errorMiddleware);

By placing security headers, CORS policies, and compression before route definitions—and the error handler last—this configuration ensures the application remains both secure and resilient.

With this architecture, developers can build scalable, type-safe, and maintainable backend services without sacrificing clarity or reliability. The patterns outlined here are not just theoretical—they’re battle-tested in production environments where data integrity and uptime are non-negotiable. As your application grows, these foundations will scale alongside your needs, ensuring long-term stability and developer productivity.