Modern Rendering Architectures

အကောင်းဆုံးနှစ်ခုကို ပေါင်းစပ်ခြင်း

အရင်သင်ခန်းစာတွေမှာ Server-Side Rendering (SSR) က ပထမဆုံး load ဖြစ်ချိန်မြန်တာ၊ Client-Side Rendering (CSR) က interactivity ကောင်းတာ စတဲ့ သူ့အားသာချက်၊ အားနည်းချက်တွေအကြောင်း လေ့လာခဲ့ပါတယ်။ ခေတ်မီနည်းပညာတွေကတော့ ဒီအားသာချက်နှစ်ခုလုံးကို အားနည်းချက်မရှိဘဲ ရရှိနိုင်အောင် ကြိုးစားလာကြပါတယ်။

Islands Architecture

ဘာလဲ - ဒါက webpage တွေကို တည်ဆောက်တဲ့ နည်းလမ်းတစ်ခုပါ။ ပုံသေ(static)ဖြစ်ပြီး အပြန်အလှန်တုံ့ပြန်မှုမရှိတဲ့(non-interactive) အကြောင်းအရာတွေ (စာသား၊ ရိုးရိုးပုံများ) ကို server ကနေ HTML အဖြစ် ပို့လွှတ်ပါတယ်။ ဒါပေမဲ့ အပြန်အလှန်တုံ့ပြန်နိုင်တဲ့ အစိတ်အပိုင်းလေးတွေ (ဥပမာ - carousel၊ search widget၊ buttons တွေ) ကိုတော့ သီးခြား “ကျွန်း” လေးတွေအဖြစ် သဘောထားပြီး JavaScript ကို သုံးပါတယ်။
ဘာကြောင့်မြန်တာလဲ - စာမျက်နှာရဲ့ အစိတ်အပိုင်းအများစုက JavaScript လုံးဝမလိုအပ်တဲ့၊ မြန်မြန်ဆန်ဆန် load ဖြစ်တဲ့ static HTML တွေဖြစ်နေလို့ပါ။ Browser က Page တစ်ခုလုံးကို မဟုတ်ဘဲ၊ အဲဒီ ကျွန်းလေးတွေကိုပဲ “hydrate” (အပြန်အလှန်တုံ့ပြန်နိုင်အောင်) လုပ်ပေးရုံပါပဲ။ ဒါကြောင့် စစချင်း load လုပ်ရမယ့် JavaScript ပမာဏ သိသိသာသာနည်းသွားပြီး Time to Interactive (TTI) အလွန်မြန်ဆန်လာစေပါတယ်။
ဥပမာနှိုင်းယှဉ်ချက် - စက္ကူကတ်ထူပြားနဲ့လုပ်ထားတဲ့ မြေပုံကြီးတစ်ခုကို မြင်ယောင်ကြည့်ပါ။ သူ့ရဲ့ အစိတ်အပိုင်းအများစုက ကြည့်ဖို့သက်သက်ပါပဲ။ ဒါပေမဲ့ အဲဒီမြေပုံပေါ်မှာ အလုပ်လုပ်တဲ့ ခလုတ်အနည်းငယ် (“ကျွန်း” တွေ) ပါဝင်ပါတယ်။ သင်က မြေပုံတစ်ခုလုံးကို ပါဝါပေးစရာမလိုဘဲ၊ တကယ်အလုပ်လုပ်တဲ့ ခလုတ်လေးတွေအတွက် ဘက်ထရီအသေးလေးတွေပဲ လိုအပ်သလိုပါပဲ။

Partial Hydration (တစ်စိတ်တစ်ပိုင်း အသက်သွင်းခြင်း)

ဘာလဲ - ဒါက Islands Architecture နဲ့ နီးနီးစပ်စပ်တူတဲ့ သဘောတရားတစ်ခုပါ။ application တစ်ခုလုံးကို တစ်ပြိုင်နက်တည်း “hydrate” လုပ်မယ့်အစား၊ Partial Hydration က မတူညီတဲ့ component တွေကို အချိန်မတူဘဲ၊ ဒါမှမဟုတ် လိုအပ်မှသာ interactive ဖြစ်အောင် လုပ်ဆောင်ပေးပါတယ်။
ဥပမာ - Webpage တစ်ခုရဲ့ အပေါ်ဆုံးက header က ချက်ချင်း interactive ဖြစ်သွားနိုင်ပေမယ့်၊ စာမျက်နှာအောက်ခြေက ရှုပ်ထွေးတဲ့ comment section ကိုတော့ user က အောက်ကို scroll ဆွဲချပြီး အဲဒီနေရာရောက်မှသာ သူ့ရဲ့ JavaScript ကို load လုပ်ပြီး interactive ဖြစ်အောင် လုပ်ဆောင်စေတာမျိုးပါ။
ဘာကြောင့်မြန်တာလဲ - ဒါက browser လုပ်ရမယ့်အလုပ်တွေကို ခွဲဝေပေးလိုက်ပြီး အရေးအကြီးဆုံး အစိတ်အပိုင်းတွေကို အရင်ဆုံး တုံ့ပြန်မှုကောင်းအောင် ဦးစားပေးလိုက်တာကြောင့်ဖြစ်ပါတယ်။

Edge Computing & Edge Functions

ဘာလဲ - ဒါက server-side မှာလုပ်ရတဲ့ အလုပ်တချို့ကို origin server တစ်ခုတည်းကနေ မဟုတ်ဘဲ၊ “edge” (အစွန်း) လို့ခေါ်တဲ့၊ User နဲ့ အနီးဆုံးနေရာမှာရှိတဲ့ CDN server တွေဆီကို ရွှေ့ပြောင်းလုပ်ဆောင်စေတာပါ။
ဘယ်လိုအလုပ်လုပ်လဲ - CDN ရဲ့ edge server တွေက static ဖိုင်တွေကို cache လုပ်ထားရုံသာမကဘဲ၊ Codes အသေးစားလေးတွေ (Edge Functions) ကိုပါ run နိုင်ပါတယ်။ သူတို့က content ကို user အလိုက်ပြောင်းလဲပေးတာ (personalize content)၊ A/B testing လုပ်တာ၊ ဒါမှမဟုတ် သင့် original server ဆီ request မရောက်ခင်မှာ database ကနေ data ဆွဲတာမျိုးတွေ လုပ်ဆောင်နိုင်ပါတယ်။
ဘာကြောင့်မြန်တာလဲ - ဒါက dynamic content တွေအတွက် user နဲ့ server ကြား အပြန်အလှန်သွားချိန် (round-trip time) ကို သိသိသာသာလျှော့ချပေးပြီး၊ personalized Page တွေအတွက်တောင် Time To First Byte (TTFB) ကို အလွန်မြန်ဆန်စေပါတယ်။
ဥပမာနှိုင်းယှဉ်ချက် - နေ့စဉ် promotion ကိုသိဖို့ Pizza ရုံးချုပ်ကြီး (origin server) ကို ဖုန်းဆက်မေးမြန်းမယ့်အစား၊ ကိုယ့်မြို့က pizza ဆိုင်ခွဲလေး (edge server) ကပဲ promotion ကို တိုက်ရိုက်ပြောပြပြီး order ပါ တစ်ခါတည်းလက်ခံလိုက်သလိုပါပဲ။