DEV Community

Theodor Heiselberg
Theodor Heiselberg

Posted on

Production Parity: Routing Local Traffic with a Reverse Proxy

#webdev

When building modern web applications, it’s common to have a frontend (like a Single Page Application) and a backend API running on different ports. This setup introduces friction—especially when it comes to routing and security during local development.

The Problem: Port Mismatch

Most frontend code expects to call the backend API at a specific route, such as /api/endpoint. However, locally, your backend might run on localhost:5130 while the frontend is served on localhost:9876. This mismatch leads to:

  • CORS Issues: Browsers block requests between different ports for security.

  • Environment-Specific Code: Needing logic to switch between local and production URLs.

  • Onboarding Complexity: New developers must manage multiple addresses and configurations.

The Solution: A Reverse Proxy

A reverse proxy like Nginx acts as a single entry point. By listening on a unified port (e.g., localhost:8314), it streamlines the workflow:

  • Uniform Routing: The frontend calls /api/... regardless of the environment

  • Transparent Forwarding: Nginx intercepts /api/ requests and forwards them to the backend servic

  • Local Parity: Your development environment architecture closely mirrors production

Configuration: The Hosts File

To use a custom domain (like myapp.test), you must update your local hosts file. This tells your OS to route traffic for that domain to your local machine.

On macOS: Edit /etc/hosts using >sudo nano /etc/hosts.

In Devcontainers: Ensure your Linux-based (Debian/Alpine) containers can resolve the host.

Add a line such as: 127.0.0.1 myapp.test

A Note on TLDs
Choosing the right Top-Level Domain matters:

.test / .localhost: Recommended. These are reserved for local use and testing.

.local: Can cause delays on macOS due to mDNS (Bonjour) conflicts.

.dev / .foo: These are on the HSTS Preload List, meaning browsers will force HTTPS. If you use these, you must configure SSL certificates in your proxy.

Benefits

  • Consistency: Frontend code remains identical across all environments

  • Simplicity: No more CORS headaches or complex URL configurations

  • Automation: Tools like site-config-loader work easily with Nginx to handle configurations for the frontend

A complete example on how I use this setup myself can be seen here: Link!

Top comments (0)