2 posts tagged with "best-practices"

At some point in almost every React + Vite project, someone drops the backend URL into a VITE_API_URL env var and moves on. It works, the demo passes, nobody thinks about it again. Then a few months later you're staring at your own production bundle in DevTools and your internal API host is sitting right there in plain text for anyone to read.

There's a cleaner way to do this, and it's the approach we standardize on. The frontend only ever calls same-origin relative paths under a single prefix: /api. The real backend, storage, and WebSocket hosts stay in a proxy layer (Vite's dev server while you're developing, nginx or Caddy or a CDN in production) and never make it into the JS that ships to the browser. This post walks through how to set that up and the mistakes to watch for.

Your application deployed. The CI pipeline went green. The health endpoint returned 200 OK. And then, three minutes later, the first real user request exploded in production with ECONNREFUSED because DATABASE_URL was never set in the new environment.

This class of incident is entirely preventable. The fix is not better monitoring or smarter alerting. It is making the application refuse to start when it is not ready to serve traffic.

This post covers exactly how to do that across two runtimes: NestJS and ASP.NET Core. The pattern is the same in both: validate environment variables first, probe every external service second, and only then bind the HTTP server and accept connections.