Rendering Trade-off များနှင့် Hydration၊ Hybrid Rendering

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

CSR၊ SSR နှင့် SSG တို့ဟာ ပြိုင်ဆိုင်နေတဲ့ brand သုံးမျိုး မဟုတ်ပါဘူး၊ မေးခွန်းတစ်ခုတည်းအတွက် အဖြေမတူညီတဲ့ သုံးမျိုးသာ ဖြစ်ပြီး dimension အနည်းငယ်ကို side-by-side နှိုင်းယှဉ်ကြည့်ရင် trade-off တွေကို ချက်ချင်းမြင်နိုင်ပါတယ်။

ဒီ strategy သုံးမျိုးကို ဘုံ dimension တွေအလိုက် နှိုင်းယှဉ်ကြည့်ခြင်းက မှုန်ဝါးနေတဲ့ ကြိုက်နှစ်သက်မှုကို page ရဲ့ တကယ့် ကန့်သတ်ချက်များအပေါ် အခြေခံထားတဲ့ ခိုင်မာသော ဆုံးဖြတ်ချက်တစ်ခုအဖြစ် ပြောင်းလဲပေးပါတယ်။ rendering ဘယ်နေရာမှာ ဖြစ်လဲ, HTML ဘယ်အချိန်မှာ တကယ်အသင့်ဖြစ်လဲ, dynamic content ကို ဘယ်လောက်ကောင်းစွာ ကိုင်တွယ်နိုင်လဲ, CDN edge မှာ ဘယ်လောက်ချီးသာစွာ cache လုပ်နိုင်လဲ, server capacity ဘယ်လောက်လိုအပ်ပြီး ကုန်ကျစရိတ် ဘယ်လောက်ရှိလဲ ဆိုတာတွေကို အောက်ပါ table မှာ တစ်ခုချင်းစီ နှိုင်းယှဉ်ထားပါတယ်။

Dimension	CSR / SSR / SSG
Where rendering happens	CSR: browser ထဲမှာ။ SSR: server ပေါ်မှာ။ SSG: build machine ပေါ်မှာ ကြိုတင်ပြီး။
When HTML is generated	CSR: browser ထဲမှာ JavaScript run ပြီးနောက်။ SSR: request time မှာ။ SSG: build time မှာ တစ်ကြိမ်တည်း။
Dynamic content support	CSR: ကောင်းသည်, client ဘက်ကနေ fresh data fetch လုပ်သည်။ SSR: ကောင်းသည်, request တိုင်း fresh ဖြစ်သည်။ SSG: client-side fetch အပို မပါဘဲ အားနည်းသည်။
Caching at a CDN	CSR: app shell ကိုသာ cache လုပ်နိုင်သည်။ SSR: ခက်ခဲသည်, request တိုင်း response ကွဲပြားနိုင်သည်။ SSG: အလွန်ကောင်းသည်, page တစ်ခုလုံး static file ဖြစ်သည်။
Server capacity needed	CSR: နည်းသည်, static file အများစု serve လုပ်သည်။ SSR: များသည်, request တိုင်း render လုပ်သည်။ SSG: build step ပြီးနောက် အလွန်နည်းသည်။
Typical use case	CSR: interactive app, dashboard များ။ SSR: personalize လုပ်ထားသော ဒါမှမဟုတ် မကြာခဏပြောင်းလဲသော page များ။ SSG: documentation, blog, marketing page များ။
SEO considerations	CSR: crawler များအတွက် အထူးဂရုစိုက်ရနိုင်သည်။ SSR: crawler များအတွက် content ချက်ချင်းမြင်ရသည်။ SSG: content ချက်ချင်းမြင်ရပြီး တည်ငြိမ်သည်။
Performance considerations	CSR: ပထမ paint နှေးသော်လည်း load ပြီးရင် မြန်သည်။ SSR: ပထမ content မြန်သော်လည်း request တစ်ခုချင်းစီ အလုပ်ပိုသည်။ SSG: CDN မှ ဖြစ်နိုင်ဆုံး အမြန်ဆုံး ပေးပို့နိုင်သည်။

HTML သည် browser ဆီရောက်ပြီးနောက်တောင် application အများစုက interactive ဖြစ်ဖို့ JavaScript လိုအပ်နေဆဲပါတယ် — button နှိပ်ခြင်း၊ menu ဖွင့်ခြင်း၊ page အပြည့် reload မလုပ်ဘဲ form တင်ခြင်းစသည်တို့ပါ။

JavaScript က server ကနေပို့လာပြီးသား မြင်နေရတဲ့ HTML ပေါ်မှာ behavior ကို ပူးတွဲပေးတဲ့ ဒီ process ကို ဒီ pattern ကို သုံးတဲ့ framework တွေမှာ hydration လို့ မကြာခဏ ခေါ်ကြပါတယ်။ Browser က page ကို အစကနေ ပြန်ဆောက်စရာ မလိုပါဘူး၊ ရှိပြီးသား markup ကို ပြန်သုံးပြီး event handling ကို အပေါ်ကနေ ချိတ်ဆက်ပေးရုံပါပဲ။

Real application တွေက page တိုင်းအတွက် rendering model တစ်ခုတည်းကို ခဏတောင် ရှားရှားပါးပါးသာ ဆုံးဖြတ်ကျင့်သုံးကြပါတယ်။ ထုတ်ကုန်တစ်ခုတည်းကပဲ marketing page တွေကို CDN မှ static file အဖြစ် serve လုပ်ပြီး၊ personalize လုပ်ထားတဲ့ dashboard ကို server ပေါ်မှာ request တစ်ခုချင်းစီ render လုပ်ကာ၊ comment box ဒါမှမဟုတ် live chart လို widget သေးသေးလေးကို client ဘက်မှာသာ အပြည့်အဝ run စေနိုင်ပါတယ်။

ဒီရောနှောမှုကို hybrid rendering လို့ခေါ်ပြီး application ရဲ့ အစိတ်အပိုင်းတစ်ခုချင်းစီက site တစ်ခုလုံးအပေါ် စည်းမျဉ်းတစ်ခုတည်းကို အတင်းသုံးမနေဘဲ ကိုယ်ပိုင် requirement နဲ့ ကိုက်ညီတဲ့ strategy ကို သုံးနိုင်စေပါတယ်။

text

ONE APP, THREE RENDERING STRATEGIES
-----------------------------------
ONE APP, THREE RENDERING STRATEGIES
--------------------------------------
              [ One Web Application ]
                       |
      -----------------------------------------
      |                |                       |
 Marketing page   Dashboard page         Comment widget
  (SSG)             (SSR)                  (CSR)
      |                |                       |
 Built once at    Server renders          Loaded once, then
 build time,      fresh HTML per          runs fully in the
 served from      request; JS             browser; fetches
 a CDN             hydrates after           its own data

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

team သေးသေးလေးတစ်ခုက ဆောက်လုပ်ထားတဲ့ ကုမ္ပဏီ website တစ်ခုကို စိတ်ကူးကြည့်ပါ။ homepage, pricing page နဲ့ blog တို့ဟာ visit တစ်ခုနဲ့တစ်ခုကြား ရှားရှားပါးပါးသာ ပြောင်းလဲတာမို့ build time မှာ တစ်ကြိမ်တည်း ဖန်တီးပြီး CDN ကနေ static file အဖြစ် serve လုပ်ကြပါတယ် — နေရာတိုင်းမှာ မြန်ဆန်၊ host ကုန်ကျစရိတ် သက်သာ၊ cache လုပ်ရလွယ်ကူပါတယ်။

login ဝင်ထားတဲ့ customer dashboard ကတော့ မတူညီပါဘူး — အခုလက်ရှိ ဘယ်သူ login ဝင်နေလဲဆိုတာပေါ် အတိအကျ မူတည်နေတဲ့ account balance, order history, setting တွေကို ပြသပါတယ်၊ ဒါကြောင့် server က request တစ်ခုချင်းစီအတွက် ဒီ page ကို fresh ဆောက်ပေးပြီး JavaScript က နောက်ပိုင်း click နဲ့ form တင်ခြင်းတွေကို ကိုင်တွယ်ဖို့ hydrate လုပ်ပေးပါတယ်။

ဒီ dashboard ထဲမှာ ထည့်ထားတဲ့ live chart တစ်ခုက ပတ်ဝန်းကျင် page ကို reload မလုပ်ဘဲ စက္ကန့်အနည်းငယ်တိုင်း update ဖြစ်ပါတယ်၊ ဒါကြောင့် ကိုယ်ပိုင် data ကို သီးခြား fetch လုပ်တဲ့ client-side rendered widget သေးသေးလေးအဖြစ် ဆောက်ထားပါတယ်။

ဒီဆုံးဖြတ်ချက် သုံးခုကို တစ်ခုနဲ့တစ်ခု ဆက်စပ်မှုမရှိဘဲ လုပ်ခဲ့တာ မဟုတ်ပါဘူး — page ဒါမှမဟုတ် component တစ်ခုချင်းစီက တကယ်ဘာလိုအပ်လဲဆိုတာကို မေးပြီးမှ အဲ့ဒါကို ဖြေရှင်းပေးနိုင်တဲ့ အရိုးရှင်းဆုံး strategy ကို ရွေးချယ်ခဲ့ခြင်းသာဖြစ်ပါတယ်၊ ဒါကြောင့်ပဲ real site အများစုက pure CSR, pure SSR ဒါမှမဟုတ် pure SSG မဟုတ်ဘဲ hybrid ဖြစ်သွားကြတာပါ။

CSR, SSR, SSG တို့သည် rendering ဘယ်နေရာ/ဘယ်အချိန်ဖြစ်သနည်း, dynamic content support, caching, server needs, typical use case များတွင် ကွဲပြားသည်။
hydration သည် page ကို အစကနေ ပြန်မဆောက်ဘဲ browser ထဲရှိပြီးသား HTML ပေါ်တွင် interactive behavior ကို ပူးတွဲပေးသည်။
real application အများစုသည် strategy တစ်ခုတည်းရွေးမည့်အစား page သို့မဟုတ် component မတူညီသည်များတွင် strategy ရောနှောအသုံးပြုသော hybrid rendering ကို သုံးကြသည်။

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

javascript

function recommendRenderingStrategy({ needsSEO, needsRealtimeData, contentChangesPerUser, updateFrequency }) {
  const isFrequentlyDynamic =
    needsRealtimeData || updateFrequency === "seconds" || updateFrequency === "minutes";
  if (contentChangesPerUser || isFrequentlyDynamic) {
    return needsSEO ? "SSR" : "CSR";
  }
  return "SSG";
}

function recommendRenderingForSite(pages) {
  return pages.map((page) => ({
    page: page.name,
    strategy: recommendRenderingStrategy(page),
  }));
}

const site = [
  { name: "Homepage", needsSEO: true, needsRealtimeData: false, contentChangesPerUser: false, updateFrequency: "never" },
  { name: "Pricing page", needsSEO: true, needsRealtimeData: false, contentChangesPerUser: false, updateFrequency: "never" },
  { name: "Product page (live stock count)", needsSEO: true, needsRealtimeData: true, contentChangesPerUser: false, updateFrequency: "seconds" },
  { name: "Customer dashboard", needsSEO: false, needsRealtimeData: true, contentChangesPerUser: true, updateFrequency: "seconds" },
  { name: "Live chart widget", needsSEO: false, needsRealtimeData: true, contentChangesPerUser: true, updateFrequency: "seconds" },
];

const plan = recommendRenderingForSite(site);
plan.forEach((entry) => console.log(`${entry.page}: ${entry.strategy}`));

const uniqueStrategies = new Set(plan.map((entry) => entry.strategy));
console.log(`\nDistinct strategies used across this one site: ${uniqueStrategies.size}`);
console.log(`(${[...uniqueStrategies].join(", ")}) -- this is a hybrid site.`);

You should see

Site plan က page တစ်ခုချင်းစီအတွက် အကြံပြုချက်ကို ပရင့်ထုတ်ပါတယ် — Homepage: SSG, Pricing page: SSG, Product page (live stock count): SSR, Customer dashboard: CSR, Live chart widget: CSR — ပြီးရင် distinct strategy သုံးမျိုး သုံးထားကြောင်း report ပြပြီး site ဟာ hybrid ဖြစ်ကြောင်း အတည်ပြုပါတယ်။

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

သင်သုံးနေတဲ့ real website တစ်ခု (ဘဏ်, စျေးဆိုင်, သတင်းဆိုက်) ကို ယူပြီး page တွေရဲ့ ပြုမူပုံပေါ် မူတည်ပြီး ဘယ် page က SSG, SSR ဒါမှမဟုတ် CSR ဖြစ်နိုင်လဲ ခန့်မှန်းကြည့်ပါ — မြန်ပြီးမပြောင်းလဲတာ vs personalize vs highly interactive ဆိုတာကို ကြည့်ပါ။

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

site တစ်ခုလုံးက rendering strategy တစ်ခုတည်းသာ ရွေးရမယ်လို့ ယူဆတာ — real site အများစုက page တစ်ခုချင်းစီအလိုက် strategy ရောနှောသုံးကြပါတယ်။

hydration ကို initial render နဲ့ ရောထွေးတာ — hydration သည် browser ထဲမှာ ရှိနှင့်ပြီးသား HTML ပေါ်မှာ behavior ကိုသာ ပူးတွဲပေးခြင်းဖြစ်ပါတယ်။

MDN — Hydration (Glossary) — How the Web Works