API Design: REST vs gRPC

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

REST နဲ့ gRPC ဟာ core ပြဿနာတစ်ခုတည်းကို ဖြေရှင်းကြပါတယ် — program တစ်ခုက network ကတစ်ဆင့် program တစ်ခုရဲ့ functionality ကို ခေါ်ဆိုနိုင်ခြင်းပါ — ဒါပေမဲ့ ဦးစားပေးချက် မတူပါဘူး။ REST က အရာအားလုံးကို resource (lesson, user) အဖြစ် model လုပ်ပြီး URL တွေနဲ့ ရည်ညွှန်းပါတယ်၊ standard HTTP verb တွေ (GET, POST, PUT, DELETE) နဲ့ ကိုင်တွယ်ပြီး ဖတ်ရလွယ်တဲ့ JSON နဲ့ အများအားဖြင့် ဒေတာလဲလှယ်ပါတယ်။ ဒီဖတ်ရလွယ်မှုနဲ့ plain HTTP အပေါ် မှီခိုမှုက browser ဒါမှမဟုတ် curl နဲ့ debug လုပ်ဖို့ လွယ်ကူစေပြီး client language မည်သည့်ဘာသာစကားကမဆို သုံးဖို့ လွယ်ကူပြီး caller ကို ထိန်းချုပ်မထားနိုင်တဲ့ public API အတွက် သဘာဝကျ ကိုက်ညီပါတယ်။ gRPC ကတော့ .proto file တစ်ခုမှာ ရှေ့ကတည်းက strict contract ကို definitions လုပ်ထားပါတယ် — method name, request/response shape, type အတိအကျ — ပြီးရင် လိုအပ်တဲ့ language အတွက် client/server code ကို generate လုပ်ပါတယ်။ HTTP/2 အပေါ်မှာ run ပြီး text JSON အစား compact binary protobuf နဲ့ serialize လုပ်ပါတယ် — ဒါက parse လုပ်ဖို့ သိသိသာသာ မြန်ပြီး network ပေါ်မှာ size သေးလို့ bidirectional streaming ကို native အနေနဲ့ support ပါတယ်။ ကုန်ကျစရိတ်ကတော့ tool မပါဘဲ payload ကို ဖတ်လို့မရတာနဲ့ ဘက်နှစ်ဘက်စလုံးက .proto contract ကို share ရမှာပါ။ ဒီ trade-off — readability နဲ့ looseness ကို speed နဲ့ strictness နဲ့ လဲလှယ်ခြင်း — ကြောင့်ပဲ REST က public API တွေမှာ လွှမ်းမိုးပြီး gRPC က speed အရေးကြီးတဲ့ internal service-to-service call တွေမှာ လွှမ်းမိုးနေတာပါ။

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

Thuta Learning ဟာ API နှစ်မျိုးကို ဖွင့်ပေးထားပါတယ်။ Public REST API က third-party developer, mobile app, browser extension တွေကို tutorial content နဲ့ student progress ကို plain HTTPS နဲ့ JSON နဲ့ ရယူခွင့်ပေးပါတယ် — ဘယ်သူမဆို document ဖတ်ပြီး curl နဲ့ minute အနည်းငယ်အတွင်း integrate စလုပ်နိုင်ပါတယ်၊ open ecosystem တစ်ခုအတွက် လိုအပ်ချက်အတိအကျပါပဲ။ ဒါပေမဲ့ internal အနေနဲ့ lesson-service က page load တစ်ခုမှာ progress-service နဲ့ recommendation-service ကို ဆယ်ကြိမ်ကျော် data တောင်းရတဲ့အခါ team က ဒီ service တွေကြားမှာ gRPC ကို သုံးပါတယ် — strict protobuf contract က field mismatch တွေကို production မှာမဟုတ်ဘဲ compile time မှာ ဖမ်းမိပြီး binary protocol က internal call တစ်ခုချင်းစီရဲ့ latency ကို သိသိသာသာ လျှော့ချပေးပါတယ်၊ ဒါက platform တစ်ခုလုံးမှာ တစ်စက္ကန့်ကို ထောင်ချီ ဖြစ်ပွားနေတဲ့ call တွေအတွက် အရေးကြီးပါတယ်။

REST က resource URL, HTTP verb, ဖတ်ရလွယ်တဲ့ JSON သုံးပြီး client မည်သည့်ဘာသာစကားကမဆို debug လုပ်ဖို့နဲ့ သုံးဖို့ လွယ်ကူပါတယ်။
gRPC က HTTP/2 အပေါ်မှာ binary serialization နဲ့ တင်းကျပ်တဲ့ protobuf contract သုံးပါတယ် — ပိုမြန်ပြီး native streaming ကို support ပေးပါတယ်။
REST က ထိန်းချုပ်မထားနိုင်တဲ့ client တွေနဲ့ public API အတွက် သင့်တော်ပြီး gRPC က speed နဲ့ strict type အရေးကြီးတဲ့ internal service-to-service calls အတွက် သင့်တော်ပါတယ်။

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

text

                          PUBLIC-FACING
  Browser / Mobile App / 3rd-party Dev
        |
        |  REST over HTTPS, JSON
        |  GET /api/lessons/42
        v
  +--------------------+
  |  Tutorial Platform  | <-- readable, debuggable with curl,
  |     Public API      |     any language can call it, loose
  +--------------------+     coupling to caller = good for public
        |
        |  INTERNAL, same team controls both ends
        v
  +----------------+  gRPC/protobuf   +-------------------+
  | lesson-service | <-------------> | progress-service  |
  +----------------+  binary, HTTP/2  +-------------------+
        ^                strict typed contract, fast,
        |                streaming supported = good for
        |                high-volume internal calls
  +---------------------+
  | recommendation-svc  |
  +---------------------+

You should see

Diagram က REST ဟာ platform ထိန်းချုပ်မထားတဲ့ client တွေဆီကို ရင်ဆိုင်ပြီး readability နဲ့ loose coupling ကို ဦးစားပေးတာနဲ့ gRPC ကတော့ platform အပြည့်ထိန်းချုပ်ထားတဲ့ internal service တွေကို ချိတ်ဆက်ပြီး speed နဲ့ strict contract ကို ဦးစားပေးတာကို ပြသထားပါတယ်။

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

Thuta Learning ရဲ့ lesson-service နဲ့ progress-service ကြား student တစ်ဦးရဲ့ course completion percentage ကို ရယူတဲ့ gRPC call အတွက် .proto-style contract (method name, request fields, response fields) ကို ဒီဇိုင်းဆွဲပါ။ ပြီးရင် အလားတူ REST endpoint (URL, verb, JSON shape) ကို ရေးပြီး နှိုင်းယှဉ်ပါ။

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

ထိန်းချုပ်မထားနိုင်တဲ့ third-party developer တွေ သုံးမယ့် public API အတွက် gRPC ကို သုံးတာ — external developer အများစုက protobuf client တွေကို လွယ်လွယ်ကူကူ generate လုပ်ဖို့ ဒါမှမဟုတ် binary payload ကို စစ်ဆေးဖို့ မလွယ်ကူပါဘူး၊ documentation ကောင်းကောင်းရှိတဲ့ REST/JSON API နဲ့ယှဉ်ရင် integration ခက်ခဲပါတယ်။

High-frequency internal service call တွေအတွက် REST/JSON ကို သုံးပြီး latency နဲ့ CPU cost ကြောင့် အံ့ဩနေတာ — JSON parsing နဲ့ payload size ကြီးမားမှုက internal microservice call တွေရဲ့ volume အတိုင်းအတာမှာ မြန်မြန်ဆန်ဆန် ပေါင်းလာနိုင်ပြီး ဒါက gRPC ဖန်တီးခဲ့ရတဲ့ အကြောင်းရင်းအတိအကျပါပဲ။

gRPC — Introduction — System Design