Environment Variables: The Thing I Wish I'd Used Properly From Day One

When a project is small, putting configuration directly into the code is incredibly convenient.

An API URL goes into a service file. A project ID goes into a constant. While experimenting, an API key might end up there too. Everything is visible, everything works and there is no extra setup.

Then the project starts growing.

I began running into this while connecting APIs and Firebase services. The values I needed on my machine were not necessarily the values I would want in production, and some of them definitely did not belong in a Git repository.

Environment variables give those values a separate place to live.

Instead of writing something like:

const apiUrl = "https://some-service.com";

the application can read it from configuration:

const apiUrl = process.env.API_URL;

The exact mechanism depends on the framework, but the principle is the important part: the code describes how the application works; configuration describes the environment in which it is running.

That makes switching between environments much easier and avoids scattering configuration across random files.

It also makes .gitignore more important. A local .env file can contain values that should not be committed, while an .env.example can show which variables the project expects without containing the real values.

One thing I am also learning is that environment variables do not magically make every value secret. In a client application, especially a mobile or browser app, values that are bundled into the application can still potentially be extracted. Keeping a key out of Git is useful, but it is not the same as keeping a true server-side secret.

Still, separating configuration from source code is a habit I wish I had adopted earlier. It makes the project cleaner now and will make development and production environments much easier to manage later.