တိုက်ရိုက်အပြန်အလှန်ဆက်သွယ်ခြင်း - Web API

အရင်အခန်းမှာ၊ ကျွန်တော်တို့ monolith အကြီးကြီးကို microservice အသေးလေးတွေအဖြစ် ခွဲထုတ်ခဲ့ပါတယ်။ အခုတော့ မေးခွန်းအသစ်တွေနဲ့ ရင်ဆိုင်ရပါပြီ - ဒီ service တွေက တစ်ခုနဲ့တစ်ခု ဘယ်လိုစကားပြောကြမလဲ။ ပြီးတော့ service တစ်ခုစီက သူ့ရဲ့ data ကိုယ်စီ ပိုင်ဆိုင်ထားတယ်ဆိုရင်၊ system တစ်ခုလုံးမှာရှိတဲ့ data တွေကို ဘယ်လိုစီမံခန့်ခွဲမလဲ။ ဒီအခန်းမှာတော့ distributed system တွေမှာ အပြန်အလှန်ဆက်သွယ်ပြောဆိုခြင်းနဲ့ data စီမံခန့်ခွဲခြင်းအတွက် မရှိမဖြစ်လိုအပ်တဲ့ pattern တွေကို လေ့လာပါမယ်။

ရည်ရွယ်ချက်

Service များအကြား တိုက်ရိုက် request/response ပြုလုပ်ဆက်သွယ်သည့် နည်းလမ်းများဖြစ်သော REST, GraphQL, နှင့် gRPC တို့၏ အသုံးများသော ပုံစံများကို နားလည်ရန်။

APIs: Service များကြားက သဘောတူညီချက်များ

API (Application Programming Interface) ဆိုတာ service တစ်ခုက တခြား service တွေကို ပေးထားတဲ့ တရားဝင်သဘောတူညီချက် ဒါမှမဟုတ် “menu” တစ်ခုနဲ့တူပါတယ်။ တခြား service တစ်ခုက ဘာတွေကို တောင်းဆိုနိုင်သလဲ၊ ပြီးတော့ ဘာတွေကို ပြန်ရမလဲဆိုတာကို အတိအကျ သတ်မှတ်ပေးပါတယ်။ Service တွေက တစ်ခုနဲ့တစ်ခု ရောနှောချိတ်ဆက်မနေဘဲ အတူတကွအလုပ်လုပ်နိုင်ဖို့အတွက် ကောင်းမွန်စွာဒီဇိုင်းဆွဲထားတဲ့၊ ရှင်းလင်းတဲ့ API တွေ လိုအပ်ပါတယ်။

REST: Web ရဲ့ အဓိကဘာသာစကား

REST (Representational State Transfer) ဆိုတာက web API တွေဖန်တီးရာမှာ အကျယ်ပြန့်ဆုံးအသုံးပြုတဲ့ architectural style တစ်ခုပါ။ ဒါက web ရဲ့ အခြေခံမူတွေပေါ်မှာပဲ တည်ဆောက်ထားပါတယ်။

• အဓိက သဘောတရားများ -

  1. Resources - အရာအားလုံးက resource ဖြစ်ပြီး၊ သူ့မှာ သီးခြားလိပ်စာ (URL) တစ်ခုရှိပါတယ်။ ဥပမာ - /users/123 ဆိုတာ သီးသန့် user တစ်ယောက်အတွက် resource ပါ။ /orders ဆိုတာက order အားလုံးရဲ့ collection ပါ။

  2. HTTP Verbs (Methods) - ဒီ resource တွေအပေါ်မှာ အလုပ်လုပ်ဖို့အတွက် standard HTTP method တွေကို သုံးပါတယ်။

  • GET: Resource တစ်ခုကို ဖတ်ဖို့ (ဥပမာ - GET /users/123 နဲ့ user အချက်အလက်ယူတာ)။

  • POST: Resource အသစ်တစ်ခု ဖန်တီးဖို့ (ဥပမာ - POST /orders နဲ့ order အသစ်လုပ်တာ)။

  • PUT: Resource တစ်ခုကို update လုပ်ဖို့ (ဥပမာ - PUT /users/123 နဲ့ user အချက်အလက်ပြင်တာ)။

  • DELETE: Resource တစ်ခုကို ဖယ်ရှားဖို့ (ဥပမာ - DELETE /users/123)။

  3. Statelessness (အရင် request တွေကို မှတ်မထားခြင်း): ဒါက အလွန်အရေးကြီးတဲ့ စည်းမျဉ်းတစ်ခုပါ။ Client က ပို့လိုက်တဲ့ request တစ်ခုချင်းစီမှာ server က အလုပ်လုပ်ဖို့လိုအပ်တဲ့ အချက်အလက်အားလုံး ပါဝင်ရပါမယ်။ Server က အဲဒီ client ဆီက အရင်က ပို့ခဲ့တဲ့ request တွေကို ဘာတစ်ခုမှ မမှတ်ထားပါဘူး။

အကြွေစေ့ထည့်ပြီး ပစ္စည်းထုတ်တဲ့စက် (Vending Machine) - REST API က Vending Machine တစ်လုံးနဲ့တူပါတယ်။ သင်က သီးခြားလိပ်စာတစ်ခု (C4) ကိုသွားတယ်၊ လုပ်ဆောင်ချက်တစ်ခုအတွက် ခလုတ် (GET) ကိုနှိပ်တယ်၊ ပြီးတော့ ပစ္စည်းကို ရတယ်။ စက်က သင်ဘယ်သူလဲ၊ အရင်တစ်ခေါက် ဘာဝယ်သွားလဲဆိုတာကို မသိပါဘူး။ အရောင်းအဝယ်တစ်ခုချင်းစီက သီးခြားလွတ်လပ်ပါတယ်။

GraphQL: Data တောင်းဆိုရာမှာ ပိုမိုပြောင်းလွယ်ပြင်လွယ်ရှိခြင်း

GraphQL ဆိုတာ Facebook က REST ရဲ့ အကန့်အသတ်တချို့ကို ဖြေရှင်းဖို့ ဒီဇိုင်းဆွဲထားတဲ့ API တွေအတွက် query language အသစ်တစ်ခုပါ။

• ဖြေရှင်းပေးတဲ့ ပြဿနာ - REST နဲ့ဆိုရင်၊ သင်က တစ်ခါတလေ data တွေ လိုအပ်တာထက် ပိုပြီးရတာ (over-fetching) ဒါမှမဟုတ် လိုအပ်တာရဖို့ အကြိမ်ကြိမ်တောင်းဆိုရတာ (under-fetching) တွေ ဖြစ်တတ်ပါတယ်။

• GraphQL ဘယ်လိုအလုပ်လုပ်လဲ - သူက client ကို request တစ်ခုတည်းနဲ့ သူ အတိအကျလိုအပ်တဲ့ data ကို တောင်းဆိုခွင့်ပေးပါတယ်။

  • Queries - Data ဖတ်ဖို့သုံးပါတယ်။ Client က သူလိုချင်တဲ့ field တွေကို အတိအကျသတ်မှတ်ပြီး query ပို့ပါတယ် (ဥပမာ - user တစ်ယောက်ရဲ့ profile တစ်ခုလုံးမဟုတ်ဘဲ၊ name နဲ့ email ကိုပဲ တောင်းတာ)။

  • Mutations - Data ရေးဖို့သုံးပါတယ် (အသစ်ဖန်တီးခြင်း၊ ပြင်ဆင်ခြင်း၊ ဖျက်ခြင်း)။

  • Subscriptions - Real-time update တွေအတွက်သုံးပါတယ်၊ server က data ပြောင်းလဲသွားတဲ့အခါ client ဆီကို data “တွန်းပို့” နိုင်ပါတယ်။

စားသောက်ဆိုင်မှာ မှာစားတာ - REST က သတ်မှတ်ထားတဲ့ “combo meal” တစ်စုံကို မှာသလိုပါပဲ—သင်က ဘာဂါတစ်ခုတည်းပဲ လိုချင်ရင်တောင်၊ ဘာဂါ၊ အာလူးကြော်၊ အအေး သုံးမျိုးလုံး ရပါတယ်။ GraphQL ကတော့ စားပွဲထိုးကို “ကျွန်တော် ဘာဂါအသားပြား၊ ဒိန်ခဲတစ်ချပ်နဲ့ အပေါ်ဘက်ပေါင်မုန့်ပဲ လိုချင်တယ်၊ sauce နဲ့ အောက်ဘက်ပေါင်မုန့်မလိုဘူး” လို့ ပြောလိုက်သလိုပါပဲ။ သင်က လိုချင်တာကို အတိအကျတောင်းဆိုလို့ ရပါတယ်။

gRPC: အလွန်မြန်သော အတွင်းပိုင်းဆက်သွယ်မှုများအတွက်

• ဘာလဲ - Google က ထုတ်လုပ်ထားတဲ့ high-performance communication framework တစ်ခုပါ။

• ဘယ်အချိန်သုံးမလဲ - အဓိကအားဖြင့် သင့်ရဲ့ အတွင်းပိုင်း microservice များအချင်းချင်း ကြား မြန်ဆန်ထိရောက်စွာ ဆက်သွယ်ဖို့အတွက် သုံးပါတယ်။ Browser တွေ၊ mobile app တွေက ခေါ်မယ့် public API တွေအတွက်တော့ ယေဘုယျအားဖြင့် မသုံးပါဘူး။

• ဘာကြောင့်မြန်တာလဲ - သူက JSON လို text-based format အစား၊ binary format (Protobuf) ကို သုံးတဲ့အတွက်၊ ပိုသေးငယ်ပြီး process လုပ်ဖို့ ပိုမြန်ပါတယ်။