คุณจัดการ configuration และ secret ใน Node อย่างไร?

Question

Accepted Answer

Configuration (database URL, API key, port, feature flag) ควรอยู่ **นอกโค้ด** ใน environment variable — ไม่ควร hardcode เด็ดขาด วิธีนี้ทำให้ secret อยู่นอก source control และทำให้โค้ดเดียวกันรันได้ทั้งใน dev, staging และ production ด้วยการตั้งค่าที่ต่างกัน

## หลักการ: ดึง config จาก environment

```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;
```

สิ่งนี้เป็นไปตามหลัก **twelve-factor app**: แยก config ออกจากโค้ดอย่างเข้มงวด เพื่อให้การ deploy ไป environment ใหม่หมายถึงการเปลี่ยน env var ไม่ใช่การเปลี่ยนโค้ด

## Local development: ไฟล์ .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;
```

ไฟล์ `.env` เก็บ config สำหรับ local และ **ต้องถูก gitignored** ให้ commit ไฟล์ `.env.example` (ที่มีแต่ key ไม่มีค่าจริง) เพื่อบันทึกว่าจำเป็นต้องมีอะไรบ้าง

## Validate config ตอนเริ่มต้น

```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
```

การ validate env var ตอน boot (ด้วย zod/envalid) หมายความว่า secret ที่ขาดหายหรือผิดรูปแบบจะ crash ทันทีพร้อมข้อความที่ชัดเจน — ดีกว่าความล้มเหลวที่น่าสับสนตอน runtime ลึกลงไปใน request มาก

## Secret ใน production

```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.
```

## รวมศูนย์การเข้าถึง

```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 };
```

## ทำไมจึงสำคัญ

การจัดการ config และ secret ที่ถูกต้องเป็นความจำเป็นทั้งด้าน **ความปลอดภัย** และ **การปฏิบัติการ**

การ hardcode secret ทำให้มันรั่วเข้าไปใน version control (เป็นการรั่วไหลที่ร้ายแรงและพบบ่อย) การผสม config เข้าไปในโค้ดทำให้การ deploy ข้าม environment เป็นเรื่องเจ็บปวด

แนวทางมาตรฐาน — env var, ไฟล์ `.env` ที่ gitignored สำหรับ local dev, `.env.example` สำหรับเอกสาร, การ validate ตอนเริ่มต้น และ secret manager ของแพลตฟอร์มใน production — ช่วยให้ secret ปลอดภัย ทำให้แอป portable ข้าม environment และทำให้การตั้งค่าผิดปรากฏขึ้นแต่เนิ่น ๆ

มันเป็นพื้นฐานของการรัน Node app อย่างมีความรับผิดชอบ