# Node.js: Environment Variables

## Node.js Environment Variables \[Best Practices]

1. Never commit commit `.env` files 1.a For production, use a secrets manager like `AWS Secrets Manager` or `HashiCorp Vault` 1.b Improve developer onboarding by providing a `.env.example` file with all required variables (without real values) and documentation in your `README`.
2. Multi-layered approach using dotenv with environment-specific files such as `.env.dev` and `.env.prod`
3. Never use `process.env` directly throughout your codebase. Instead create a centralized config object that validates required variables and provides proper type conversion

More

* always hash the passwords i.e. use `bcryt` library
* always encode the env variables i.e. encode it `base-64`

<https://deadsimplechat.com/blog/environment-variables-in-nodejs/>

***

## Secret Environment Variables \[Best Practices]

tl;dr: even if your frontend app is very small, you are obliged to make a Backend API, otherwise you expose all your secret environment variables such as database passwords.

Secrets like API keys for secure services (e.g., database access, private APIs, admin credentials) should only live and run on the `backend`.

The best practice is to not access secrets like `SECRET_API_KEY` in frontend code at all.

If you include them in your `frontend` JavaScript, they’re visible to anyone in DevTools or by inspecting the bundle.

#### In short

* `backend` projects in nodejs+express: it's all good, go for it
* `frontend` projects (i.e. in react): use a proxy or backend api to securely call third party services

***

## Frontend Projects and Secret Environment Variables \[Best Practices]

Instead of exposing your secret to the client, use a Backend API or Proxy:

* Your frontend calls your own API server (or serverless function).
* The backend uses `SECRET_API_KEY` securely to call the third-party service.
* The backend returns only the non-sensitive response to the frontend.

Bonus points

* You control rate limits
* You can filter/sanitize
* You can rotate secrets

#### Example

Frontend code

> ```
> const res = await fetch('/api/data');
> const data = await res.json();
> ```

Backend code - Express, Next.js API route, or serverless function

> ```
> app.get('/api/data', async (req, res) => {
>   const response = await fetch('https://api.service.com/data', {
>     headers: {
>       'Authorization': `Bearer ${process.env.SECRET_API_KEY}`,
>     },
>   });
>   const data = await response.json();
>   res.json(data); // filtered if needed
> });
> ```

***

## Common Beginner Mistakes

Make sure

* `.env` is in the root folder
* `.gitignore` contains `.env`, `.env.development`, `.env.production`, `nodemon.json`
* `readme` documents the required environment variables in `.env`, `nodemon.json` and/or other files
* when deploying on a Cloud Platforms-as-a-Service, you figure out if environment variables were included in the final javascript bundle, if not you must be set them up (prob manually) on the platform

***

## JS Bundlers and Environment Variables

tl;dr: included in final bundle? it depends

#### Webpack

For webpack, you must use an additional plugin such as `dotenv-webpack` or `DefinePlugin`.

You manually define which environment variables to expose - which are then included in the final bundle.

Note: it's not super clear how this works, need to investigate

#### Vite

Vite has built-in `.env` support. It automatically loads `.env`, `.env.development`, etc.

Variables prefixed with `VITE_` are exposed to the client - and then included in the final bundle.

***

## Environment Variables Setup On `Webpack`

c.f. dedicated notes file on `webpack`

***

## Environment Variables Setup On `Vite`

c.f. dedicated notes file on `vite`