What Is an API Gateway? The Front Door AI Builds for Your Backend

Why AI Coders Need to Know This

Open any AI-generated backend project and there's a good chance you'll find an API gateway — or at least gateway-like code — somewhere in the stack. Ask Claude to "build me a SaaS with user accounts, a dashboard, and Stripe payments" and watch what happens: it creates separate route files for auth, payments, and data, then wires them through a central server file that checks tokens, enforces limits, and decides where each request goes.

That central file? That's doing the job of an API gateway. Sometimes AI will even suggest dedicated gateway tools like Kong, Traefik, or AWS API Gateway, especially if you mention microservices anywhere in your prompt.

Here's why this matters to you as a vibe coder: API gateways are one of the most over-prescribed patterns in AI-generated code. They're genuinely critical for companies like Stripe (which handles billions of API calls across hundreds of internal services) and completely unnecessary for a solo builder running one Express server on a $5 VPS.

But — and this is the key part — the concepts behind API gateways are things you use every day whether you know it or not. Every time AI adds authentication middleware, rate limiting, or request logging to your server, it's implementing gateway responsibilities. Understanding what an API gateway does helps you understand what your AI-generated backend is actually doing under the hood, which means you can debug it, simplify it, and make better decisions about what to keep and what to throw away.

The Hotel Analogy (30 Seconds to Understanding)

Imagine a hotel with five departments: housekeeping, room service, the spa, the concierge, and valet parking. Without a front desk, every guest would need to find each department themselves, prove they're a guest every single time, and figure out which floor to go to for what. Chaos.

The front desk solves this. Every guest checks in at one place. The front desk:

• Verifies identity — "Are you actually a guest here?" (authentication)
• Routes requests — "Room service? Dial 3. Spa? Take the elevator to floor 4." (routing)
• Enforces limits — "Sorry, only two pool towels per room." (rate limiting)
• Logs everything — "Room 412 ordered room service at 8pm." (request logging)
• Translates — "The guest speaks French? Let me call our French-speaking staff." (request transformation)

That's an API gateway. One front door. All traffic goes through it. It handles the common stuff so each department (service) can focus on what it does best.

Real Scenario: "Build Me a Backend with Multiple Services"

Let's say you're building a fitness tracking app. You want user accounts, workout logging, and a payment system for premium features. You tell Claude:

That last sentence — "a single entry point that handles auth and rate limiting for all routes" — is essentially asking for an API gateway. Here's what Claude generates:

What AI Generated

// gateway.js — The API Gateway (single entry point)
const express = require('express');
const rateLimit = require('express-rate-limit');
const cors = require('cors');
const helmet = require('helmet');
const morgan = require('morgan');
const jwt = require('jsonwebtoken');

const app = express();

// ─── Global Middleware (applies to ALL requests) ───
app.use(helmet());                    // Security headers
app.use(cors({ origin: 'https://myfitnessapp.com' }));  // CORS
app.use(express.json());              // Parse JSON bodies
app.use(morgan('combined'));          // Request logging

// ─── Rate Limiting ───
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,          // 15-minute window
  max: 100,                           // 100 requests per window
  standardHeaders: true,
  legacyHeaders: false,
  message: { error: 'Too many requests. Try again in 15 minutes.' }
});
app.use('/api/', limiter);

// ─── Authentication Middleware ───
const authenticate = (req, res, next) => {
  // Public routes skip auth
  const publicPaths = ['/api/auth/login', '/api/auth/register'];
  if (publicPaths.includes(req.path)) return next();

  const token = req.headers.authorization?.split(' ')[1];
  if (!token) {
    return res.status(401).json({ error: 'No token provided' });
  }

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded;
    next();
  } catch (err) {
    return res.status(401).json({ error: 'Invalid or expired token' });
  }
};
app.use('/api/', authenticate);

// ─── Route Mounting (gateway routes to services) ───
const authRoutes = require('./routes/auth');
const workoutRoutes = require('./routes/workouts');
const paymentRoutes = require('./routes/payments');
const healthRoutes = require('./routes/health');

app.use('/api/auth', authRoutes);
app.use('/api/workouts', workoutRoutes);
app.use('/api/payments', paymentRoutes);
app.use('/api/health', healthRoutes);

// ─── Global Error Handler ───
app.use((err, req, res, next) => {
  console.error(`[Gateway Error] ${req.method} ${req.path}:`, err.message);
  res.status(err.status || 500).json({
    error: process.env.NODE_ENV === 'production'
      ? 'Internal server error'
      : err.message
  });
});

// ─── Start ───
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`API Gateway running on port ${PORT}`);
});

Understanding Each Part

Let's walk through what the gateway is doing. Every single line serves a purpose, and once you understand the pattern, you'll recognize it in every backend project AI generates for you.

The Security Layer

app.use(helmet());
app.use(cors({ origin: 'https://myfitnessapp.com' }));

helmet() adds security headers to every response — things like preventing your site from being loaded in an iframe (clickjacking protection) and telling browsers not to sniff MIME types. CORS controls which websites are allowed to make requests to your API. By setting the origin to your app's domain, you're saying "only my frontend can talk to this backend." These run on every single request before anything else happens. The gateway handles this once instead of every route file repeating it.

Rate Limiting

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,    // 15-minute window
  max: 100,                     // 100 requests per window
  ...
});
app.use('/api/', limiter);

This says: "Any single IP address can make at most 100 requests every 15 minutes." Without this, someone could hammer your API with thousands of requests per second — crashing your server, racking up database costs, or brute-forcing passwords. Rate limiting is one of the most important things a gateway does, and it's applied globally here so no route can accidentally skip it.

Authentication

const authenticate = (req, res, next) => {
  const publicPaths = ['/api/auth/login', '/api/auth/register'];
  if (publicPaths.includes(req.path)) return next();

  const token = req.headers.authorization?.split(' ')[1];
  // ... verify token ...
  req.user = decoded;
  next();
};
app.use('/api/', authenticate);

This is the bouncer. Every request to /api/ gets checked for a valid JWT token — except login and registration (because obviously you can't be authenticated before you log in). If the token is valid, the decoded user info gets attached to req.user so every downstream route knows who's making the request without having to check again. This is a gateway's bread and butter: authenticate once at the door, trust everything inside.

Route Mounting

app.use('/api/auth', authRoutes);
app.use('/api/workouts', workoutRoutes);
app.use('/api/payments', paymentRoutes);

This is the routing layer — the part that decides where requests go. A request to /api/workouts/log gets sent to the workouts route handler. A request to /api/payments/subscribe goes to payments. In a full microservices setup, these wouldn't be local route files — they'd be completely separate servers, and the gateway would proxy requests to them over the network. For a single-server app like this, route files accomplish the same organizational pattern without the complexity.

Error Handling

app.use((err, req, res, next) => {
  console.error(`[Gateway Error] ${req.method} ${req.path}:`, err.message);
  res.status(err.status || 500).json({
    error: process.env.NODE_ENV === 'production'
      ? 'Internal server error'
      : err.message
  });
});

The global error handler catches anything that goes wrong in any route. Notice it logs the error with the request method and path (so you can trace problems), and in production it returns a generic message instead of leaking internal details. This is a gateway responsibility: standardize error responses so your frontend always gets a consistent format, regardless of which service threw the error.

When You Actually Need a Real API Gateway

Here's the honest truth that most tutorials won't tell you: if you're reading this article, you probably don't need a dedicated API gateway yet. But you will eventually — and knowing when to upgrade from "Express middleware doing gateway stuff" to "a real gateway tool" is a valuable skill.

You DON'T need a dedicated gateway when:

• You have one backend server — Express middleware handles routing, auth, and rate limiting just fine. Adding a gateway in front of a single server is like hiring a receptionist for a one-person office.
• You're in the building phase — Premature architecture kills projects. Build the thing first. Add infrastructure when the thing works and has users.
• Your traffic is modest — Under 10,000 requests per day? Your Express server is not breaking a sweat. Save the gateway for scaling problems you actually have.

You DO need a gateway when:

• You have multiple backend services — Once your app grows into separate services (auth service, payment service, notification service running on different ports or servers), a gateway gives your frontend one URL to talk to instead of juggling five.
• You need service-level rate limiting — Maybe your payment endpoint should allow 10 requests/minute but your search endpoint should allow 100. A gateway makes per-route limiting clean.
• You need API versioning — When you release v2 of your REST API while keeping v1 alive for existing users, a gateway routes /v1/ and /v2/ to different service versions.
• You need canary deployments — Routing 5% of traffic to the new version while 95% stays on the stable version. Gateways make this a configuration change instead of a code change.
• Multiple frontends — Web app, mobile app, and a third-party integration all hit your backend differently. A gateway can transform requests so each client gets the format it needs.

API Gateway vs. Express Middleware — What's the Difference?

If you looked at the code above and thought, "Wait, that's just… an Express server with middleware," you're absolutely right. And that's the key insight most tutorials bury under jargon.

For a single-server app, Express middleware IS your API gateway. The pattern is identical:

Gateway Feature	Express Middleware Equivalent	Dedicated Gateway Tool
Authentication	app.use(authMiddleware)	Kong JWT plugin / AWS Authorizer
Rate limiting	express-rate-limit	Kong rate-limiting plugin
CORS	cors() middleware	Gateway CORS config
Routing	app.use('/api/x', routes)	Route definitions in gateway config
Logging	morgan / custom logger	Built-in analytics dashboard
Error handling	Global error middleware	Gateway error policies

The difference shows up when you have multiple separate services. Express middleware only works within one Express server. A dedicated gateway like Kong or Traefik sits in front of multiple servers and routes traffic between them. It can also do things middleware can't: circuit breaking (automatically stop sending requests to a crashed service), load balancing across multiple instances, and protocol translation (accept HTTP from users, speak gRPC to internal services).

What AI Gets Wrong About API Gateways

AI coding tools make predictable mistakes with API gateways. Knowing these patterns saves you hours of debugging and prevents you from shipping architecture you don't need.

1. Adding a Gateway to Single-Server Apps

The most common mistake. You ask for "a backend with auth" and AI generates a separate gateway service that proxies to your one Express server. This adds a network hop, another process to manage, and zero practical benefit. If you see a gateway/ folder and a services/ folder in a project with one backend, you can safely merge them.

2. Suggesting Kong or AWS API Gateway for MVP Apps

Kong is an incredible tool — for teams managing dozens of microservices. For your fitness tracker MVP, it's like renting a tour bus to drive to the grocery store. AI suggests it because Kong appears heavily in training data. If AI recommends Kong, Traefik, or AWS API Gateway and you have fewer than three separate services, tell it: "I don't need a dedicated gateway. Use Express middleware instead."

3. Duplicating Auth in the Gateway AND Services

AI sometimes generates authentication logic in the gateway and in each individual route file. This means tokens get verified twice per request — wasteful and confusing. The whole point of a gateway is to authenticate once at the door. If your gateway verifies the JWT and attaches req.user, your route handlers should trust it without re-checking.

4. Hardcoding Service URLs

In microservices setups, AI often hardcodes service addresses like http://localhost:3001 directly in the gateway. In production, services don't run on localhost. These should be environment variables (process.env.WORKOUT_SERVICE_URL) or use service discovery. If AI hardcodes ports, refactor them to environment variables immediately.

5. Missing Health Checks

A gateway should know if a downstream service is healthy before routing traffic to it. AI almost never generates health check endpoints or circuit breaker logic. For a simple setup, at minimum add a /health route that returns 200 OK — it costs nothing and is essential for monitoring.

How to Debug API Gateway Issues with AI

Gateway problems are some of the most confusing to debug because the error happens in one place (the gateway) but the cause might be in another (the downstream service, the token, or the client). Here are the most common issues and what to tell your AI.

Problem: "401 Unauthorized" on Every Request

Common causes: The token is in the wrong header format (missing "Bearer " prefix), the JWT_SECRET env var isn't loaded (check your .env file), or the token has expired. AI can trace the exact failure point if you give it both sides.

Problem: CORS Errors After Adding Gateway

Common causes: The origin in your CORS config doesn't match your frontend URL exactly (trailing slashes matter), preflight OPTIONS requests aren't being handled, or you have CORS configured in both the gateway and the individual service (they conflict).

Problem: Requests Work Locally But Fail in Production

Common causes: The Express server is listening on a different port than nginx expects, the server didn't start successfully (check logs), or the proxy_pass URL is wrong. The term "502 Bad Gateway" literally means "the gateway tried to reach the service behind it and couldn't."

Problem: Rate Limiter Blocks Legitimate Users

Common causes: Behind a proxy or load balancer, all requests appear to come from the same IP (the proxy's IP). You need app.set('trust proxy', 1) in Express so the rate limiter reads the real IP from X-Forwarded-For headers. AI generates rate limiters but almost never adds the trust proxy setting.

Real API Gateway Tools (When You're Ready)

When your app grows to the point where Express middleware isn't cutting it, here are the tools worth knowing about:

Kong Gateway (Open Source)

The most popular open-source API gateway. Plugin-based: add auth, rate limiting, logging, caching, and more without writing code. Great for: teams with 3+ microservices who want a battle-tested, self-hosted solution.

AWS API Gateway (Managed)

Amazon's fully managed gateway. Pay per API call, no servers to manage. Great for: apps already on AWS that need auto-scaling. Not great for: learning (the AWS console is overwhelming) or tight budgets (costs add up at scale).

Traefik (Docker-Native)

Automatically discovers services running in Docker and routes traffic to them. Great for: Docker-based deployments where services spin up and down. AI loves suggesting this one for Docker Compose setups.

nginx (The Swiss Army Knife)

Not technically an API gateway but can do most gateway jobs with configuration. Already running in front of most production apps as a reverse proxy. Great for: adding gateway-like features (rate limiting, auth, routing) without a new tool.

The Gateway Pattern — Simplified Code You Can Actually Use

Here's a minimal, production-aware gateway pattern for a single Express server. This is what you should actually ship for an MVP — not the enterprise version AI suggests:

// server.js — Minimal gateway pattern for solo builders
const express = require('express');
const cors = require('cors');
const helmet = require('helmet');
const rateLimit = require('express-rate-limit');

const app = express();

// ─── Security (always) ───
app.use(helmet());
app.use(cors({ origin: process.env.FRONTEND_URL }));
app.use(express.json({ limit: '10kb' }));  // prevent huge payloads

// ─── Rate limiting (always) ───
app.use('/api/', rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100
}));

// ─── Health check (always) ───
app.get('/health', (req, res) => res.json({ status: 'ok' }));

// ─── Auth middleware (runs before protected routes) ───
const { authenticate } = require('./middleware/auth');

// ─── Public routes ───
app.use('/api/auth', require('./routes/auth'));

// ─── Protected routes (auth required) ───
app.use('/api/workouts', authenticate, require('./routes/workouts'));
app.use('/api/payments', authenticate, require('./routes/payments'));
app.use('/api/profile', authenticate, require('./routes/profile'));

// ─── Error handler ───
app.use((err, req, res, next) => {
  const status = err.status || 500;
  console.error(`[${status}] ${req.method} ${req.path}: ${err.message}`);
  res.status(status).json({ error: err.message || 'Server error' });
});

app.listen(process.env.PORT || 3000);

Notice the differences from AI's version: auth middleware is applied per route group instead of globally (so public routes don't need a skip list), the health check is outside the rate limiter, and environment variables replace hardcoded values. This is cleaner, easier to understand, and easier to debug.

What to Learn Next

Now that you understand what an API gateway does — and when you actually need one — here are the concepts that connect directly:

Frequently Asked Questions