Third-Party Integration Architecture

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

ဒီအခန်းက skill တစ်ခုစီက ရည်ရွယ်ချက်တစ်ခုတည်းကို အလုပ်လုပ်ပေးပါတယ် — third-party API ကို ဘေးကင်းစွာ integrate လုပ်ခြင်းပါ။ default architecture ကတော့ layered ဖြစ်ပါတယ် — frontend က သင့် backend ကို ပြော၊ backend က third-party API ကို ပြော၊ backend က response ကို frontend ဆီ မရောက်ခင် validate လုပ်ပါတယ်။

ဒီ layering ဟာ အကြောင်းရင်းရှိလို့ ရှိနေတာပါ — frontend code ထဲ ထည့်ထားတဲ့ secret API key ကို developer tools ဖွင့်လိုက်တဲ့သူတိုင်း မြင်နိုင်ပါတယ် — secret လုံးဝ မဟုတ်တော့ပါ။ backend ကနေတဆင့် ပို့ခြင်းက credential ကို server-side ထားပေးပါတယ်။

Direct Frontend Call	ရမလား၊ မရဘူးလား?
Public API, no secret needed	ရပါတယ် — အထိခိုက်မခံသောအရာ မထုတ်ပေးပါ။
Client-side key made for browsers, CORS supported	ရပါတယ် — provider က ဒီအတွက် ဒီဇိုင်းလုပ်ထားတာပါ။
Secret key, privileged operation, sensitive logic	မရပါ — သင့် backend ကနေတဆင့် ပို့ပါ။

architecture ကို သိရုံသက်သက်က အလုပ်တစ်ဝက်ပဲ ဖြစ်ပါတယ် — ဘေးကင်းစွာ လုပ်ဆောင်ခြင်းက workflow တစ်ခုပါ — docs ဖတ်ခြင်း၊ credentials ဘေးကင်းစွာ သိမ်းခြင်းကနေ testing, validating, error ကိုင်တွယ်ခြင်း, logging, monitoring အထိပါ။

text

LAYERED INTEGRATION ARCHITECTURE
--------------------------------
FRONTEND  --request-->  YOUR BACKEND  --request-->  3RD-PARTY API
                                                          |
FRONTEND  <--result----  YOUR BACKEND  <--response-------+
                          (validates before trusting it)

Secrets and privileged logic live only in YOUR BACKEND, never
in code the browser can read.

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

payments provider တစ်ခု integrate လုပ်နေတယ်ဆိုပါစို့။ workflow က code မရေးခင်ကတည်းက စတင်ပါတယ် — docs ဖတ်ပါ၊ ပြီးရင် provider ရဲ့ dashboard မှာ API credentials ဖန်တီးပြီး environment variables အဖြစ် သိမ်းပါ — frontend code ဒါမှမဟုတ် Git commit ထဲ ဘယ်တော့မှ မထည့်ပါနဲ့။

၁။ Docs ဖတ်ပါ

ဘာမှ မရေးခင် ဘာကိုခေါ်နေလဲ တိကျစွာသိဖို့ ဒီအခန်းက ဖတ်ရှုအစီအစဉ်ကို သုံးပါ။

၂။ Credentials ဖန်တီးပါ

provider ရဲ့ dashboard မှာ API key သို့မဟုတ် token ထုတ်ပါ။

၃။ ဘေးကင်းစွာ သိမ်းပါ

server ပေါ်က environment variables အဖြစ်၊ frontend code ဒါမှမဟုတ် Git ထဲ ဘယ်တော့မှ မထည့်ပါနဲ့။

၄။ Manually အရင်စမ်းပါ

code မရှိသေးခင် sandbox ကို Postman request နဲ့ ကိုက်ကြည့်ခြင်းက အခြေခံများကို အတည်ပြုပေးပါတယ်။

၅။ Server Integration တည်ဆောက်ပါ

browser မဟုတ်ဘဲ သင့် backend ကသာ တကယ့် call ကို လုပ်ပါတယ်။

၆။ Response ကို Validate လုပ်ပါ

third-party response ကို မျက်စိမှိတ် မယုံပါနဲ့ — အလုပ်မလုပ်ခင် ပုံစံနှင့် တန်ဖိုးများကို စစ်ပါ။

၇။ Error များ ကိုင်တွယ်ပါ

failure မတူရင် ကိုင်တွယ်ပုံ မတူပါ — card declined က timeout နှင့် ကွဲပါတယ်။

၈။ Rate Limits ကိုင်တွယ်ပါ

traffic spike တစ်ခုက account ကို throttle မခံရအောင် documented limits ကို လေးစားပါ။

၉။ Failure များကို ဘေးကင်းစွာ Log ချပါ

နောက်မှ debug လုပ်ဖို့ လုံလောက်တဲ့ အသေးစိတ်၊ ဒါပေမယ့် secret key စစ်စစ်ကို ဘယ်တော့မှ မထည့်ပါနဲ့။

၁၀။ Monitoring ထည့်ပါ

တိတ်တဆိတ် failure တစ်ခု ရက်များစွာကြာမှ customer complaint ကနေ မဟုတ်ဘဲ ချက်ချင်း ပေါ်လာဖို့ပါ။

ဘေးအကင်းဆုံး default architecture က third-party call များကို သင့် backend ကနေတဆင့် ပို့ပြီး frontend မမြင်ခင် response ကို validate လုပ်ပါတယ်။
Direct frontend-to-API call ကို public, secret မလိုအပ်, browser-designed, CORS-supported case များမှာသာ လက်ခံနိုင်ပါတယ် — ကျန်တာအားလုံးက backend ပေါ်မှာ ရှိသင့်ပါတယ်။
ဆယ်ဆင့် workflow — docs, credentials, ဘေးကင်းသိမ်းခြင်း, manual test, တည်ဆောက်ခြင်း, validate, error handling, rate limits, ဘေးကင်း logging, monitoring — ကသာ အလုပ်ဖြစ်တဲ့ demo တစ်ခုကို production-ready integration အဖြစ် ပြောင်းပေးပါတယ်။

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

javascript

// Checks a described integration setup against the key
// requirements of the safe integration workflow, and reports what's
// still missing before it's production-ready.
function checkProductionReadiness(setup) {
  const requirements = [
    { key: "credentialsReadFromDocs", label: "Read the docs and know what credentials are needed" },
    { key: "hasCredentialsStored", label: "Credentials stored safely (not in frontend code or Git)" },
    { key: "testedManuallyFirst", label: "Tested the API manually (e.g. in Postman) before coding" },
    { key: "hasServerIntegration", label: "Calls go through your backend, not directly from the browser" },
    { key: "hasResponseValidation", label: "Backend validates the third-party response before trusting it" },
    { key: "hasErrorHandling", label: "Errors from the third-party API are caught and handled" },
    { key: "hasRateLimitHandling", label: "Rate limit responses are detected and handled (e.g. retry/backoff)" },
    { key: "hasLogging", label: "Failures are logged safely, without leaking secrets" },
    { key: "hasMonitoring", label: "Monitoring/alerts exist for ongoing integration health" },
  ];

  const missing = requirements.filter((r) => !setup[r.key]).map((r) => r.label);

  return {
    total: requirements.length,
    met: requirements.length - missing.length,
    missing,
    productionReady: missing.length === 0,
  };
}

const solidSetup = {
  credentialsReadFromDocs: true,
  hasCredentialsStored: true,
  testedManuallyFirst: true,
  hasServerIntegration: true,
  hasResponseValidation: true,
  hasErrorHandling: true,
  hasRateLimitHandling: true,
  hasLogging: true,
  hasMonitoring: false,
};

const riskySetup = {
  credentialsReadFromDocs: true,
  hasCredentialsStored: false,
  testedManuallyFirst: true,
  hasServerIntegration: false,
  hasResponseValidation: false,
  hasErrorHandling: true,
  hasRateLimitHandling: false,
  hasLogging: false,
  hasMonitoring: false,
};

console.log("Solid setup:", checkProductionReadiness(solidSetup));
console.log("Risky setup:", checkProductionReadiness(riskySetup));

You should see

Run လုပ်ရင် ရလာမည့် တကယ့် output:

Solid setup: {
  total: 9,
  met: 8,
  missing: [ 'Monitoring/alerts exist for ongoing integration health' ],
  productionReady: false
}
Risky setup: {
  total: 9,
  met: 3,
  missing: [
    'Credentials stored safely (not in frontend code or Git)',
    'Calls go through your backend, not directly from the browser',
    'Backend validates the third-party response before trusting it',
    'Rate limit responses are detected and handled (e.g. retry/backoff)',
    'Failures are logged safely, without leaking secrets',
    'Monitoring/alerts exist for ongoing integration health'
  ],
  productionReady: false
}

solid setup က monitoring တစ်ခုတည်း ကျန်ရုံနဲ့ production-ready ဖြစ်တော့မှာပါ; risky setup ကတော့ အရေးကြီးဆုံး ကာကွယ်မှု နှစ်ခု — server-side routing နှင့် response validation — ပျောက်နေပါတယ်၊ ဒီအခန်းရဲ့ architecture က ပိတ်ဖို့ တည်ဆောက်ထားတဲ့ ကွက်လပ်တွေအတိအကျပါပဲ။

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

သင်သိထားတဲ့ real ဒါမှမဟုတ် စီစဉ်ထားတဲ့ integration တစ်ခု (ဒါမှမဟုတ် ယုတ္တိရှိတဲ့ တစ်ခု တီထွင်ပါ) ကို ဖော်ပြပါ။ အထက်ပါလို setup object တစ်ခုကို ရိုးသားစွာ ဖြည့်ပါ၊ checkProductionReadiness ဖြင့် run ကြည့်ပြီး ပျောက်နေသော requirement တစ်ခုစီအတွက် ဒီကွက်လပ်ကို ပိတ်ဖို့ ဘာတည်ဆောက်ရမလဲ ဒါမှမဟုတ် ဘာပြောင်းရမလဲ ဆိုတာ စာကြောင်းတစ်ကြောင်းစီ ရေးပါ။

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

"feature တစ်ခုအတွက်ပဲလေ" ဆိုပြီး secret API key ကို frontend code ထဲ တိုက်ရိုက်ထည့်ခြင်း — ရည်ရွယ်ချက် ဘာပဲဖြစ်ဖြစ် browser ကနေ ဖတ်လို့ရသွားပါတယ်။

third-party response ကို validate မလုပ်ဘဲ ယုံကြည်ခြင်း — bug ရှိသော ဒါမှမဟုတ် ထိခိုက်ခံထားရသော provider response က သင့် system ထဲကို တိုက်ရိုက် မစစ်ဆေးဘဲ စီးဝင်သွားနိုင်ပါတယ်။

OWASP API Security Top 10 (2023) — API Integration & Webhooks