Project: Database ပါတဲ့ Full-Stack App တစ်ခု Deploy လုပ်ခြင်း

နားလည်ထားရမယ့် အချက်

Full-stack app တစ်ခုက အနည်းဆုံး piece သုံးခု ကွဲထွက်ပါတယ် — frontend၊ API/backend နဲ့ database — ပြီး production ထဲမှာ piece တစ်ခုစီက platform ကွဲပြားပြီး သီးခြားစီ deploy ဖြစ်နိုင်ပါတယ်။

Static-vs-dynamic hosting split — piece ဘယ်ဟာက build output ဖြစ်ပြီး ဘယ်ဟာက running process ဖြစ်လဲ
Environment variables and secrets — piece တွေ တစ်ခုနဲ့တစ်ခု ဘယ်လို ရှာတွေ့/authenticate လုပ်လဲ
Production databases — managed ဖြစ်ပြီး backup ရှိ၊ connection string တစ်ခုတည်းနဲ့ပဲ ထိရောက်
CI/CD basics — relevant code ပြောင်းတိုင်း automatic deploy ဖြစ်ခြင်း

Frontend ဟာ React/Vue/Next.js app ပုံမှန်ဆိုရင် static ဒါမှမဟုတ် static နီးပါး output ဖြစ်ပြီး static site project အတိုင်းပဲ deploy လုပ်နိုင်ပါတယ်။ backend ကတော့ မတူပါဘူး — database နဲ့ စကားပြောရ၊ secret ကိုင်ထားရတဲ့ process ဖြစ်လို့ platform အမျိုးအစား မတူတာဆီ deploy လုပ်ရပါတယ်။

နေရာ	ဘာရှိလဲ
Frontend (build time)	NEXT_PUBLIC_API_URL လို public URL variable တစ်ခု၊ browser က API ဘယ်မှာလဲသိအောင် client bundle ထဲ bake ဝင်ထားတယ်။
Backend (runtime)	Private variable တွေ: DATABASE_URL, JWT_SECRET, third-party API key များ — browser ဆီ လုံးဝ မထုတ်ပြပါ။

Production database ဆိုတာ managed service တစ်ခု

local SQLite file ဒါမှမဟုတ် laptop Docker container ထဲက database နဲ့မတူဘဲ production database ဟာ backup၊ connection pooling၊ failover တွေကို ကိုယ်တိုင် ကိုင်တွယ်ပေးတယ် — backend က connection string နဲ့ authenticate လုပ်ရုံပါပဲ။

ဒီနေရာမှာလည်း CI/CD က ထပ်အရေးပါတယ် — working pipeline တစ်ခုက code ပြောင်းတိုင်း frontend နဲ့ backend ကို automatic deploy လုပ်ပေးလို့ "deploy" ဆိုတာ main ကို merge တိုင်း အတူတူဖြစ်လာတဲ့ အရာတစ်ခု ဖြစ်သွားတယ်။

text

FULL-STACK APP: FRONTEND + API + DATABASE
-----------------------------------------
[BROWSER]
    |
    | HTTPS request
    v
[FRONTEND]  (static/edge host, e.g. a React or Next.js build)
    |  env: NEXT_PUBLIC_API_URL=https://api.example.com
    |
    | fetch() to API_URL
    v
[API / BACKEND]  (separate deploy: container host or PaaS)
    |  env: DATABASE_URL=postgres://...
    |  env: JWT_SECRET=...
    |
    | SQL query over a TLS connection
    v
[DATABASE]  (managed production database)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Codebase ကို ခွဲပါ

frontend directory တစ်ခုနဲ့ backend/API directory တစ်ခု (ဒါမှမဟုတ် repo နှစ်ခု)၊ တစ်ခုစီ သီးခြား deploy လုပ်နိုင်။

Backend ကို deploy လုပ်ပြီး private env var ထည့်ပါ

production database provision လုပ်ပြီး DATABASE_URL, API key, signing secret တွေကို platform dashboard ထဲမှာ တိုက်ရိုက် set လုပ်ပါ — git ထဲမပါစေရ။

Frontend ကို deploy လုပ်ပြီး public env var ထည့်ပါ

framework လိုအပ်တဲ့ public prefix သုံးပြီး API ရဲ့ public URL ကို set လုပ်ပါ၊ build ထဲ bake ဝင်သွားအောင်။

နှစ်ခုစလုံးအတွက် CI/CD ချိတ်ပါ

main ကို push တိုင်း automatic redeploy ဖြစ်အောင် deploy နှစ်ခုစလုံးကို git repository နဲ့ ချိတ်ပါ။

Production ထဲမှာ path အပြည့် test လုပ်ပါ

live frontend ကို ဖွင့်ပြီး API ကို ထိပြီး database ထိရောက်တဲ့ request တစ်ခု စမ်းပါ — local test တစ်ခုတည်း မလုံလောက်ပါ။

Full-stack deployment ရဲ့ #1 failure

value မှန်ကန်တဲ့ .env file တစ်ခု local မှာပဲ ရှိနေပြီး hosting platform အစစ်ပေါ်မှာ configure လုံးဝမလုပ်ခဲ့တာ။ app က ကိုယ့်စက်ပေါ်မှာတော့ ပြီးပြည့်စုံစွာ အလုပ်လုပ်ပေမယ့် live ဖြစ်သွားတာနဲ့ ရှုပ်ထွေးတဲ့ error ထုတ်တာ ဒါမှမဟုတ် တိတ်တဆိတ် အလုပ်လုပ်ပုံမှားသွားတာပါ။

Frontend နဲ့ backend ဟာ platform ကွဲနိုင်ပြီး environment variable တွေနဲ့ပဲ ချိတ်ထား
Production database ဟာ managed service တစ်ခုဖြစ်ပြီး secret တခြားအတိုင်း authenticate လုပ်
"Local မှာရ production မှာပျက်" ဆိုတာ almost always environment variable ပျောက်နေလို့ပဲ

အတူတူ စမ်းရေးကြည့်မယ်

javascript

function startApp(env, required) {
  const missing = required.filter((key) => !env[key] || env[key].trim() === "");

  if (missing.length > 0) {
    throw new Error(
      `Cannot start: missing required environment variable(s): ${missing.join(", ")}`
    );
  }

  console.log("Environment OK. Starting server...");
  console.log(`  API_URL      = ${env.API_URL}`);
  console.log(`  DATABASE_URL = ${env.DATABASE_URL.replace(/:[^:@]+@/, ":****@")}`);
  return true;
}

const required = ["API_URL", "DATABASE_URL", "JWT_SECRET"];

const localEnv = {
  API_URL: "http://localhost:4000",
  DATABASE_URL: "postgres://user:pass@localhost:5432/app",
  JWT_SECRET: "dev-secret",
};

const prodEnvMissingSecret = {
  API_URL: "https://api.example.com",
  DATABASE_URL: "postgres://user:pass@prod-db.example.com:5432/app",
};

console.log("--- Attempting local config ---");
startApp(localEnv, required);

console.log("\n--- Attempting production config ---");
try {
  startApp(prodEnvMissingSecret, required);
} catch (err) {
  console.error(err.message);
}

You should see

Local config အပြည့်အစုံ ပါတဲ့အခါ server စတင်ပြီး API_URL နဲ့ masked DATABASE_URL ကို log ထုတ်ပါတယ်။ Production config မှာတော့ JWT_SECRET ပျောက်နေလို့ startApp() က ရှင်းရှင်းလင်းလင်း Error တစ်ခု throw လုပ်ပါတယ်:

--- Attempting local config ---
Environment OK. Starting server...
  API_URL      = http://localhost:4000
  DATABASE_URL = postgres://user:****@localhost:5432/app

--- Attempting production config ---
Cannot start: missing required environment variable(s): JWT_SECRET

၅ မိနစ် စမ်းကြည့်

Full-stack app ရိုးရိုးလေးတစ်ခု (frontend + Express-style API + Postgres database) အတွက် လိုအပ်မယ့် environment variable တွေကို column နှစ်ခုခွဲ ရေးပါ — "frontend, public" နဲ့ "backend, private" — ပြီးရင် တစ်ခုချင်းစီကို ဘယ် platform ရဲ့ dashboard မှာ အမှန်တကယ် set လုပ်ရမလဲဆိုတာ ဖော်ပြပါ။

သတိလေးတစ်ချက်

Local .env file ထဲမှာ environment variable ကို set လုပ်ပြီး deployment platform တစ်ခုချင်းစီရဲ့ dashboard ထဲမှာလည်း လက်ဖြင့် configure လုပ်ဖို့ လိုကြောင်း မေ့သွားတာ။

Database password လို private secret ကို public/client-side environment variable အဖြစ် မှားယွင်းသုံးမိပြီး frontend ရဲ့ built JavaScript bundle ထဲ ဖော်ထုတ်မိသွားတာ။

The Twelve-Factor App — Config — Cloud & Deployment