Your app started as one backend. Then the mobile team needed a notifications service. Then billing became its own thing. Then someone added a search service, and now the React Native app is talking to four different hostnames, each with its own way of checking tokens and its own idea of rate limiting.

At some point someone in a meeting says the words "we need an API gateway". Sometimes they're right. Sometimes they've just added a fifth thing to maintain.

Let's look at what a gateway actually does, and how to tell which situation you're in.

The one-sentence version

An API gateway is a single front door for your APIs. Every client request goes to the gateway first, and the gateway decides where it goes, whether it's allowed in, and what happens on the way.

Think of the reception desk in a big office building. Visitors don't wander the corridors looking for the right department. They go to reception, show ID, get a badge, and are directed to the right floor. The departments don't each need a security guard at their door.

What a gateway does

1. Routing

The core job. Clients call one host, and the gateway forwards by path:

api.example.com/billing/*   →  billing-service
api.example.com/search/*    →  search-service
api.example.com/*           →  main-app

That sounds trivial, but it buys you a lot of freedom. You can split a service out of the monolith, move it to a different server or rewrite it entirely, and the mobile app never needs an update. The public URL is a contract; what's behind it is your business.

2. Authentication at the edge

Instead of every service validating tokens in its own way, the gateway checks the token once, rejects bad requests early, and passes trusted identity information to the services behind it (often as headers).

One caution: the services behind the gateway must only be reachable through the gateway. If they also accept traffic directly, anyone can send that "trusted" header themselves. And authentication at the gateway doesn't replace authorisation in the service. The gateway knows who you are; only the billing service knows whether you're allowed to see this invoice.

3. Rate limiting and quotas

A single place to say "100 requests per minute per API key" or "the free plan gets this much per day". Doing it at the gateway protects every service behind it, including the ones whose developers forgot.

4. Aggregation

A mobile home screen might need the user's profile, their open maintenance requests and their latest invoice. That's three services and three round trips over a mobile connection. A gateway (or a small service behind it) can fan out to all three and return one combined response.

This idea has its own name, Backend for Frontend (BFF): a thin layer shaped around what one client needs. It's especially useful for mobile apps, where every round trip is expensive.

5. The cross-cutting chores

TLS termination, CORS headers, request logging, request IDs for tracing, response caching, IP allow-lists, request size limits. None of these are exciting, all of them are needed, and doing them once beats doing them in every service.

The options, roughly

Many teams already run the first row without calling it a gateway. If Nginx sits in front of your app and routes /api to one place and / to another, you have the beginnings of one.

When it's overkill

Here's my honest take: if you have one backend, you don't need an API gateway.

A Laravel monolith already has a gateway built in. Its router is the routing. Its middleware handles authentication, rate limiting, CORS and logging. Adding a separate gateway in front of a single app gives you a new hop in every request, a new place for config to drift, and a new thing to debug at 2 a.m., in exchange for features you already had.

The same is true for most small teams with a monolith plus a couple of background workers. Workers don't receive public traffic; they don't need a front door.

Signs you've outgrown "no gateway"

• Clients have to know about several hostnames.
• Each service implements token validation slightly differently.
• You're about to publish an API to partners and need keys, quotas and usage tracking.
• Mobile screens make many sequential calls to render one view.
• You want to move or split services without forcing app updates.

The gateway trap

One last warning. Gateways are tempting places to put business logic: "just add a little transformation here", "just check this flag there". Resist it. Once business rules live in gateway config, they're invisible to the people reading the service code, rarely tested, and painful to change.

Keep the gateway boring: routing, identity, limits, logging. Everything that's about your business belongs in the services.

Summary

• A gateway is a front door: routing, auth at the edge, rate limits, aggregation and shared chores.
• Services behind it must not be reachable directly, and still check authorisation themselves.
• One backend? Your framework's router and middleware are already your gateway.
• Keep business logic out of it.

Are you running a gateway in front of your APIs right now? And if so, was it there because you needed it, or because the architecture diagram looked emptier without it?