user
GraphQL in software engineering
RESTful API တွေရှိနေရက်နဲ့ ဘာလို့ Facebook (Meta) က GraphQL ကိုတီထွင်ခဲ့တာလဲ။ GraphQL ကိုဘယ်လိုအခြေအနေတွေမှာ အသုံးပြုသင့်တာလဲ။ 
GraphQL အကြောင်းကို အရိုးရှင်းဆုံး နားလည်အောင် ရေးပြပါ။


assistant
( အောက်ပါ အကြောင်းအရာကို CodeHub with Harry မှ blogger Harry Yan ရဲ့ Aug, 2023 က content တပုဒ်မှ ကောက်နှုတ်ဖော်ပြထားပါတယ် )

GraphQL

စာအုပ်ဆိုင်တခုမှာ စာအုပ်သွားဝယ်တယ်လို့ မြင်ယောင်ကြည့်ပါ။ ကိုယ်လိုချင်တဲ့ စာအုပ်က မြသန်းတင့်ရဲ့ လွမ်းမောခဲ့ရသော တက္ကသိုလ်နွေညများဆိုတဲ့ စာအုပ်။ ဒါပေမယ့် အဲဒီဆိုင်က စာအုပ်တအုပ်ဝယ်ရင် လိုချင်တဲ့တအုပ် တင်မကပဲ အဲစာအုပ်တင်ထားတဲ့ စင်ပေါ်မှာ ရှိသမျှ အကုန် ဝယ်ရမယ်လို့ ပြောပါတယ်။ REST API တွေရဲ့ ပြဿနာက ဒါပါပဲ။ GraphQL ဆိုတာ ဒီပြဿနာတွေကို ဖြေရှင်းဖို့ ရည်ရွယ်ပြီး Meta က တီထွင်ခဲ့တဲ့ API query language တခုဖြစ်တယ်။
သမရိုးကျ Rest API တွေမှာ မလိုချင်တဲ့ data တွေ အပိုပါလာတာ၊ ဒါမှမဟုတ် data တွေ လိုချင်သလောက် မရသေးလို့ နောက်ထပ်တခါ ထပ်တောင်းရတာစတဲ့ အခက်အခဲတွေ ကြုံရပါတယ်။ GraphQL ရဲ့အိုင်ဒီယာကတော့ client တွေကို သူတို့လိုအပ်တဲ့ data ကိုသာ အတိအကျ တောင်းယူခွင့်ပေးပြီး ဒီပြဿနာတွေကို ဖြေရှင်းလိုက်ဖို့ပါပဲ။
ရှေ့တခေါက် API တွေအကြောင်း ပြောကြတုန်းက စားပွဲထိုး ဥပမာနဲ့ ရှင်းပြခဲ့ပါတယ်။ REST API တွေက menu စာအုပ်ထဲက ဟင်းပွဲကို လက်ညိုးထိုးမှာလို့ရတဲ့ သဘောဖြစ်ပြီး GraphQL ကတော့ လိုချင်တဲ့ ဟင်းလျာကို ပါဝင်ပစ္စည်း အတိအကျနဲ့ ချက်ခိုင်းလို့ရတဲ့ ပုံစံလို့ ကျွန်တော်တို့ပြောခဲ့ဖူးပါတယ်။
GraphQL ရဲ့ အဓိကအကျဆုံး အစိတ်အပိုင်းက "Schema" ဖြစ်တယ်။ Schema ဆိုတာ client တွေအနေနဲ့ server ဆီက ဘယ် data တွေ ရနိုင်တယ်။ ဘယ်လိုတောင်းယူနိုင်တယ်ဆိုတာကို ဖော်ပြထားတဲ့ သတ်မှတ်ချက်တွေပါပဲ။ ဒါကြောင့် schema ကို စားသောက်ဆိုင်တခုရဲ့ ရွေးချယ်နိုင်တဲ့ ပါဝင်ပစ္စည်းတွေနဲ့ တူတယ်လို့ တွေးကြည့်နိုင်တယ်။
client တွေအနေနဲ့ လိုအပ်တဲ့ data နဲ့ လိုချင်တဲ့ response ရဲ့ အသွင်သဏ္ဍာန်ကို server ဆီ "Query" တွေပေးပို့ပြီး တောင်းဆိုကြပါတယ်။ ဒါကြောင့် Query ဆိုတာ ကိုယ်လိုချင်တဲ့ ဟင်းပွဲအကြောင်းကို စားပွဲထိုးဆီကတဆင့် မီးဖိုချောင်ကို အသိပေးစေတာလို့ နားလည်ထားနိုင်တယ်။
client ဆီက Query တွေကိုဖတ်ပြီး response အတွက် လိုအပ်တဲ့ data တွေကို database ထဲက ဘယ် table မှာရှာပေးရမလဲ၊ ဘယ် API တွေကိုတဆင့်ပြန်ခေါ်ပေးရမလဲဆိုတာကို သိနိုင်အောင် server မှာ "Resolver" လို့ခေါ်တဲ့ဟာ ရှိပါတယ်။ ဒီတော့ resolver ဆိုတာ တောင်းဆိုလာတဲ့ ပါဝင်ပစ္စည်းတွေကို ဘယ်ကရှာရမယ်၊ ဘယ်လိုပေါင်းစပ်ရမယ်ဆိုတာ နားလည်တဲ့ စားဖိုမှူးကောင်းတယောက်နဲ့ တူပါတယ်။
server က "Response" တခုတည်ဆောက်ပြီး data တွေကို client တောင်းဆိုတဲ့ပုံစံအတိုင်း အတိအကျ ပြန်ပို့လိုက်တယ်။ ဒီ response တွေက client ကလိုချင်တဲ့အတိုင်း စီစဥ်ပေးလိုက်တဲ့ စပရှယ် ဟင်းလျာတွေဖြစ်တယ်။
GraphQL ရဲ့ အားသာချက်တွေကို ကြည့်ကြရအောင်ပါ။
GraphQL နဲ့ဆိုရင် ဆက်စပ်နေတဲ့ data တွေကို query တခုတည်းမှာတင် တောင်းလို့ရစေတဲ့အတွက် server နဲ့ client device အကြား အသွားအပြန်ခရီး အကြိမ်အရေအတွက်ကို သိသိသာသာ လျှော့ချပေးနိုင်ပါတယ်။ 
ကျွန်တော်တို့ CodeHub ရဲ့ website မှာ blog တွေ ဝင်ဖတ်တယ်လို့ ဆိုပါစို့။ blog object တခုမှာ စာရေးသူရဲ့ id ပဲထည့်ထားမှာဖြစ်တယ်။ ဒါပေမယ့် Blog View မှာတော့ author ရဲ့ id ကိုပြမှာ မဟုတ်ပဲ author ရဲ့ နာမည်၊ ဖြစ်နိုင်မယ်ဆိုရင် profile ပုံစသဖြင့် ပြထားချင်တဲ့အတွက် CodeHub ရဲ့ frontend developer တွေအနေနဲ့ backend ကို author api တခေါက်ထပ်ခေါ်ရဦးမှာပါ။ ဒါကြောင့် blog data စုံဖို့ဆိုရင် request response နှစ်စုံ ရှိသွားပါမယ်။
ဒီနေရာမှာ CodeHub ကို စင်ကာပူ၊ ဂျပန်နဲ့ အမေရိကန် ၃ နေရာ ဖြန့်ထားတာဖြစ်တဲ့အတွက် မြန်မာပြည်က စာဖတ်သူတွေဆိုရင် ကြာချိန် ပျမ်းမျှ 800 microsecond ဝန်းကျင်ရှိပါလိမ့်မယ်။ GraphQL နဲ့ဆိုရင်တော့ blog နဲ့ author ကို query တခေါက်တည်းမှာ တောင်းလို့ရစေတဲ့အတွက် ကြာချိန်ကို ထက်ဝက်လျှော့ချလိုက်နိုင်ပါတယ်။
GraphQL ရဲ့နောက်ထပ်အားသာချက်က မလိုအပ်တဲ့ data တွေ ပါမလာစေတာ ဖြစ်တယ်။ GraphQL အစား REST API မှာပဲ blog နဲ့ author ကို ပေါင်းထည့်ထားလိုက်မယ်ဆိုပါစို့။ 
အဲလိုဆိုရင် Blog Service အနေနဲ့ Author Service ကို လှမ်းခေါ်ပြီး data တောင်းနေရမှာဖြစ်လို့ client ကသာ author အချက်အလက်တွေ တကယ်မသုံးဘူးဆိုရင် မလိုအပ်ပဲ resource အလေအလွင့် ဖြစ်စေတယ်။ ဒါ့အပြင် Blog Service ကိုလည်း Author နဲ့ချည်သလို ဖြစ်သွားတဲ့အတွက် Blog ရဲ့ flexibility ကို ထိခိုက်ပါသေးတယ်။
GraphQL ရဲ့ performance က REST နဲ့စာရင် သိသိသာသာ ပိုကောင်းတယ်ဆိုပေမယ့် REST API တွေ ရဲ့ အစားထိုးစရာတခုတော့ မဟုတ်ပါဘူး။ အားနည်းချက်တွေထဲက တခုအနေနဲ့ GraphQL မှာ client တယောက်ချင်းစီက သူတို့လိုအပ်သလို query တွေပို့ပြီး တောင်းယူ​နေမှာဖြစ်လို့ data တွေ cache ထားချင်တဲ့အခါ REST ထက်ပိုအာရုံများရပါတယ်။
ဒါကြောင့် backend service တခုကို တည်ဆောက်တော့မယ်ဆိုရင် ကိုယ်ဖြေရှင်းချင်တဲ့ ပြဿနာကို တိတိကျကျ ပိုင်းဖြတ်ပြီး လိုအပ်ချက်နဲ့ ကိုက်ညီမယ့် communication စတိုင်ကို ရွေးချယ်ဖြစ်ဖို့ လိုအပ်ပါတယ်။ ဒါကတော့ software engineering ရဲ့ graphQL အကြောင်း ဖြစ်ပါတယ်။