Cum gestionezi configurația și secretele în Node?

Question

IT Interview Practice · Accepted Answer

Configurația (URL-urile bazelor de date, cheile API, porturile, steaguri de funcții) ar trebui să trăiască **în afara codului** în variabile de mediu — niciodată hardcodificate. Acest lucru ține secretele departe de controlul versiunilor și permite același cod să ruleze în dev, staging și producție cu setări diferite.

## De ce conteaza

```js
// ❌ NEVER hardcode secrets — they end up in git history forever
const dbUrl = "postgres://admin:password123@db.example.com";

// ✅ read from the environment
const dbUrl = process.env.DATABASE_URL;
const port = process.env.PORT || 3000;
```

Aceasta urmează principiul **twelve-factor app**: separare strictă a configurației de cod, deci implementarea într-un mediu nou înseamnă schimbarea variabilelor env, nu a codului.

## Dezvoltare locală: fișiere .env

```bash
# .env — local values, GITIGNORED (never committed)
DATABASE_URL=postgres://localhost/myapp_dev
JWT_SECRET=dev-secret
PORT=3000
```

```js
// load .env into process.env (older: dotenv; newer Node: --env-file flag)
import "dotenv/config";        // or: node --env-file=.env app.js
const secret = process.env.JWT_SECRET;
```

Un fișier `.env` ține configurația locală; el **trebuie să fie gitignored**. Commitează un `.env.example` (cu chei dar fără valori reale) pentru a documenta ceea ce este necesar.

## Validează configurația la pornire

```js
import { z } from "zod";

const env = z.object({
  DATABASE_URL: z.string().url(),
  JWT_SECRET: z.string().min(16),
  PORT: z.coerce.number().default(3000),
}).parse(process.env); // ❗ fail FAST at startup if config is missing/invalid
```

Validarea variabilelor env la pornire (cu zod/envalid) înseamnă că un secret lipsă sau malformat se prăbușește imediat cu un mesaj clar — mult mai bun decât o eroare de runtime confuză adânc într-o cerere.

## Secrete în producție

```text
Dev:        .env file (gitignored)
Production: injected by the platform/orchestrator —
            cloud secret managers (AWS Secrets Manager, GCP Secret Manager, Vault),
            container/orchestrator env vars, CI/CD secrets.
Never put production secrets in .env files committed or shipped with the app.
```

## Centralizează accesul

```js
// config.js — one validated config module the app imports (don't sprinkle process.env everywhere)
export const config = { dbUrl: env.DATABASE_URL, port: env.PORT };
```

## De ce conteaza

Gestiunea corespunzătoare a configurației și secretelor este atât o necesitate de **securitate**, cât și o necesitate **operațională**.

Hardcodificarea secretelor le scurge în controlul versiunilor (o încălcare serioasă și obișnuită); amestecarea configurației în cod face implementarea în diverse medii dureroasă.

Abordarea standard — variabile env, `.env` gitignored pentru dev local, `.env.example` pentru documentație, validare la pornire și manageri de secrete de platformă în producție — ține secretele sigure, face aplicația portabilă în diverse medii și expune o configurare incorectă devreme.

Este fundamental pentru rularea responsabilă a aplicațiilor Node.

De ce conteaza

Dezvoltare locală: fișiere .env

Validează configurația la pornire

Secrete în producție

Centralizează accesul

De ce conteaza

Întrebări conexe