Infrastructure
Reverse proxies, explained
You run three apps on one server — a blog, an API, a dashboard. The internet only knows one address. Something has to sit at the front, look at each incoming request, and send it to the right place. That something is a reverse proxy, and if you've ever configured Nginx or Apache virtual hosts, you've already met one.
Forward vs reverse, quickly
A forward proxy sits in front of clients and represents them to the world (a corporate proxy, a VPN). A reverse proxy sits in front of servers and represents them to clients: visitors talk only to the proxy, and it decides which backend actually handles the request. The backends never face the internet directly.
What the front door does
- Routing. Send
blog.example.comto one app and/apito another — by hostname or path. (Those Apache/Nginx virtual hosts are exactly this.) - TLS termination. Handle HTTPS in one place — one spot to install certificates and decrypt — so your backends can speak plain HTTP internally. It's why the TLS handshake lives at the proxy, not in every app.
- Load balancing. Run several copies of an app and spread requests across them; if one dies, route around it.
- A choke point for cross-cutting concerns — caching, compression, rate limiting, basic auth, request logging — done once instead of in every service.
One public entrance that reads each request and quietly sends it to the right room in the back — while handling the locks (HTTPS) and the crowd control (load balancing) for everyone.
Why it's everywhere
It decouples "the address the world uses" from "where the code actually runs." You can move an app to another machine, add three more copies, or swap TLS certificates — and visitors never notice, because they only ever talk to the proxy. It's the same idea a CDN scales globally: a smart layer in front that shields, routes, and shares the load, so the things behind it can stay simple.