လွယ်လွယ်ပြောရရင် API Gateway ဆိုတာ microservices တွေ အများကြီး ရှိတဲ့ system ရဲ့ “ရှေ့တံခါးကြီး” တစ်ခုတည်း။ Client (ဖုန်း app၊ website) က တိုက်ရိုက် service တွေဆီ မသွားဘူး — gateway ကို တစ်ခုတည်း ခေါ်တယ်၊ gateway က နောက်ကွယ်က သင့်တော်တဲ့ service ဆီ ပို့ပေးတယ်။

ဥပမာ ပြောရအောင်။ ဟိုတယ်ကြီးတစ်လုံးရဲ့ reception counter ကို စဉ်းစားကြည့်ပါ။ ဧည့်သည်က အခန်းသန့်ရှင်းရေး လိုချင်ရင် housekeeping ဌာနကို တိုက်ရိုက်ဖုန်းမဆက်ဘူး၊ reception ကို ဆက်တယ်။ အစားအသောက် မှာချင်ရင်လည်း reception ပဲ။ Reception က ဘယ်ဌာနကို ပေးရမလဲ သိတယ်၊ ဧည့်သည်က ဘယ်သူလဲ စစ်တယ်၊ တောင်းဆိုချက်ကို မှတ်တမ်းတင်တယ်။ API Gateway က ဒီ reception counter ပဲ — နောက်ကွယ်မှာ service အခု ၅၀ ရှိရှိ ၁၀၀ ရှိရှိ client က တစ်နေရာတည်းကိုပဲ ဆက်သွယ်တယ်။

ဘာလို့ ဒီတံခါးကြီး လိုအပ်တာလဲ။ Microservices အကြောင်း ရေးခဲ့တဲ့ post မှာ ပြောခဲ့သလိုပဲ — app ကြီးတစ်ခုကို service အသေးလေးတွေ အများကြီး ခွဲထားတယ်။ ဥပမာ food delivery app တစ်ခုမှာ user-service, restaurant-service, order-service, payment-service, notification-service ဆိုပြီး ခွဲထားမယ်။ ဖုန်း app က ဒီ service တွေဆီ တစ်ခုချင်းစီ တိုက်ရိုက်ခေါ်ရင် ပြဿနာတွေ တက်လာတယ် —

Service တစ်ခုချင်းစီရဲ့ လိပ်စာ (URL) ကို app က သိထားရမယ်။ Service ပြောင်းရင် app ကို update လုပ်ရမယ်
Login စစ်တဲ့ code ကို service တိုင်းမှာ ထပ်ရေးရမယ်
ဘယ် service က ဘယ်လောက် request ဝင်နေလဲ စောင့်ကြည့်ဖို့ နေရာစုံ လိုက်ကြည့်ရမယ်
Service တစ်ခုကျသွားရင် app က ဘာလုပ်ရမလဲ ဆုံးဖြတ်ရမယ်

API Gateway ထားလိုက်ရင် ဒါတွေအားလုံး တစ်နေရာတည်းမှာ ဖြေရှင်းပြီးသား။ Gateway က လုပ်ပေးတာတွေက —

Routing — “/orders” ဆိုတဲ့ request ကို order-service ဆီ ပို့တာ
Authentication — login ဝင်ပြီးသားလား တစ်နေရာတည်းမှာ စစ်တာ (JWT စစ်တာမျိုး)
Rate limiting — တစ်ယောက်တည်း request အကြိမ်ရေ ထောင်ချီပို့နေရင် တားတာ
Request/response transformation — client လိုချင်တဲ့ ပုံစံနဲ့ service ပေးတဲ့ ပုံစံ မတူရင် ပြောင်းပေးတာ
Logging & monitoring — ဘယ် request ဘယ်သွားလဲ မှတ်တမ်းတစ်နေရာတည်း
Caching — ခဏခဏ တောင်းတဲ့ data ကို gateway မှာတင် သိမ်းထားပြီး service ကို မမေးတော့တာ

နာမည်ကြီး API Gateway tool တွေက Kong, AWS API Gateway, Nginx (gateway အနေနဲ့ သုံးလို့ရတယ်), Traefik, Apigee (Google)။ သေးသေးလေး project ဆိုရင် Express.js မှာ ကိုယ်တိုင် gateway လေး ရေးလို့ရတယ် — အဓိကအလုပ်က request လက်ခံပြီး သင့်တော်တဲ့ service ဆီ ပြန်ပို့တာပဲ။

သတိထားရမှာက API Gateway ကိုယ်တိုင်က single point of failure ဖြစ်နိုင်တယ်။ ဟိုတယ် reception ပိတ်သွားရင် ဧည့်သည်ဘယ်သူမှ ဘာမှ လုပ်လို့မရသလိုမျိုး — gateway ကျသွားရင် service တွေ ကောင်းနေရင်တောင် client က ရောက်လို့မရဘူး။ ဒါကြောင့် gateway ကို ကိုယ်တိုင် highly available ဖြစ်အောင် (အခု ၂-၃ ခု run ပြီး load balancer ခံထားတာ) တည်ဆောက်ရတယ်။ Failover အကြောင်း ရေးခဲ့တဲ့ post က အတွေးအခေါ်ပဲ။

နောက်တစ်ချက်က gateway မှာ logic တွေ အများကြီး စုပုံမထားဖို့။ Gateway က “တံခါးစောင့်” သက်သက် ဖြစ်သင့်တယ် — စစ်ဆေးတာ၊ ပို့ပေးတာ၊ မှတ်တမ်းတင်တာ။ Business logic (ဥပမာ “ဒီ order ကို discount ဘယ်လောက်ပေးမလဲ”) ကို gateway ထဲ ထည့်မိရင် gateway ကြီးလာပြီး ပြင်ရခက်တဲ့ monolith အသစ် ဖြစ်သွားမယ်။ ဒါကို “fat gateway” ပြဿနာလို့ခေါ်တယ်။

ကျွန်တော် microservices project တစ်ခု စလုပ်တုန်းက gateway မထားဘဲ frontend က service တွေဆီ တိုက်ရိုက်ခေါ်ခဲ့တယ်။ Service ၃ ခုလောက်တုန်းက အဆင်ပြေတယ်၊ ၈ ခုကျော်လာတော့ frontend code က service URL တွေနဲ့ ပြည့်ပြီး တစ်ခုခု ပြောင်းတိုင်း ငိုရတယ်။ Kong ထည့်လိုက်မှ သက်သာသွားတယ်။ Service တွေ များလာရင် ရှေ့တံခါးကြီးတစ်ခု ထားတာ တကယ်လိုအပ်တဲ့ ရင်းနှီးမြှုပ်နှံမှုပဲ။ 🙂

===