API Gateways & Reverse Proxies
You'll learn to
- -Distinguish a forward proxy from a reverse proxy
- -Explain what an API Gateway centralizes
Forward Proxy vs Reverse Proxy
These two terms get mixed up constantly, and the direction matters. A forward proxy sits in front of clients: it hides the client from the server (a corporate network routing all employee traffic through one exit point, or a VPN). A reverse proxy sits in front of servers; it hides the servers from the client, and every request you've made in this course to a "web server" has almost certainly gone through one first.
A reverse proxy is a bodyguard that stands between the internet and your servers. When someone visits your website, they don't talk to your actual application server. They talk to the reverse proxy, and the proxy talks to your server on their behalf. Why the middleman? Three huge reasons: (1) SSL termination: The reverse proxy handles all the encryption/decryption of HTTPS traffic, so your application servers don't waste CPU cycles on it. (2) Security: Your actual servers are hidden behind the proxy and never directly exposed to the internet. Attackers can't target what they can't see. (3) Performance: The proxy can serve static files (images, CSS, JS) directly from disk without bothering your application server, compress responses with gzip/brotli to save bandwidth, and cache frequent responses. It's like having a receptionist who handles all the repetitive questions ('What are your hours?' 'Where are you located?') so the experts inside only handle the real work.
Examples: Nginx (the most widely used), HAProxy (high-performance TCP/HTTP proxy), Envoy (modern, from Lyft, used in service meshes), Caddy (automatic HTTPS), Traefik (Docker/K8s native)
API Gateways: The Reverse Proxy, Specialized
An API Gateway is a reverse proxy with a job description: it's the single front door for every client, and it centralizes the concerns you don't want duplicated across every backend service: authentication, rate limiting, SSL termination, and routing requests to whichever service actually owns that resource.
Think of an API Gateway as the front desk of a huge office building. You don't wander through the building looking for the accounting department yourself. You go to the front desk, say 'I need accounting,' and they buzz you through to the right floor, check your ID, and log your visit. An API Gateway is the single front door for ALL your backend services. Every request from every client, whether it's a mobile app, web browser, or partner API, goes through this one gateway. The gateway handles authentication ('is this user allowed in?'), rate limiting ('this user is sending too many requests, slow them down'), SSL termination (handling the encryption/decryption so your internal services don't have to), request routing ('this /users request goes to the User Service, this /orders request goes to the Order Service'), and sometimes even combines responses from multiple services into one clean response for the client.
Examples: AWS API Gateway, Kong, Apigee, Traefik, Netflix Zuul, Azure API Management
One gateway, many services behind it; each service focuses on its own logic instead of re-implementing auth and rate limiting.
This diagram is a preview of the Microservices module later in the course: a gateway becomes essential the moment "the backend" stops being one service.
Why put authentication and rate limiting at the gateway instead of inside each service?
"It's a common pattern, so it must be a good idea."
"Duplication and drift. If every service implements its own auth check, you now have N places that can each get it subtly wrong, and updating the policy means updating N services in lockstep. Centralizing it at the gateway means one correct implementation, one place to audit, and every service behind it can trust that a request already passed auth by the time it arrives."