နားလည်ထားရမယ့် အချက်
project တစ်ခုသည် feature တစ်ခုချင်းစီရေးသားခြင်းမှ system တစ်ခုလုံးကို ဖော်ပြခြင်းသို့ ရွေ့လျားလာသည်နှင့်တပြိုင်နက် architecture pattern နှစ်ခုက အမြဲပေါ်လာတတ်ပြီး ၎င်းနှစ်ခုစလုံးသည် ဒီ course က တစ်ခုချင်းစီ ကြိုတင်ဖော်ပြပြီးသား အစိတ်အပိုင်းများမှ လုံးလုံးလျားလျား တည်ဆောက်ထားခြင်းဖြစ်သည်။
ဒီအစိတ်အပိုင်းတွေကို label တပ်ထားတဲ့ diagram တစ်ခုအဖြစ် ပေါင်းစည်းထားတာကို မြင်ရတာက ဒီသင်ခန်းစာရဲ့ အဓိကရည်ရွယ်ချက်ပါ — DNS, CDN, frontend, backend, database တို့ ဘယ်လို ပေါင်းစပ်ပြီး မှတ်မိလွယ်, ထပ်ခါထပ်ခါ တွေ့ရနိုင်တဲ့ ပုံသဏ္ဌာန်တွေ ဖြစ်လာလဲဆိုတာ နာမည်ပေးရှင်းပြပေးမှာပါ။
Static website architecture ကတော့ နှစ်ခုထဲက ပိုရိုးရှင်းပါတယ်။ user ရဲ့ request သည် မှန်ကန်တဲ့ server ကို ရှာဖွေဖို့ DNS ကို ဖြတ်သန်းပြီး site ရဲ့ HTML, CSS, JavaScript, image file တွေကို cache လုပ်ပြီးသား CDN ဆီ ရောက်ရှိကာ request တစ်ခုချင်းစီအလိုက် server-side computation လုံးဝ မလုပ်ဘဲ CDN က ဒီ file တွေကို တိုက်ရိုက် serve လုပ်ပေးပါတယ်။
response တစ်ခု ဆောက်ဖို့ database သော်လည်းကောင်း backend logic run နေခြင်းသော်လည်းကောင်း မရှိပါဘူး၊ ဘာလို့လဲဆိုတော့ content က visitor တိုင်းအတွက် တစ်ထပ်တည်းဖြစ်ပြီး ကြိုတင်ဖန်တီးထားပြီးသားမို့ပါ။ ဒါက portfolio, documentation site, marketing page နဲ့ visitor တစ်ဦးချင်းစီအတွက် အသစ်တွက်ချက်ဖို့ မလိုတဲ့ content တိုင်းအတွက် သင့်တော်ပါတယ်။
Full-stack architecture ကတော့ static architecture ချန်ထားခဲ့တဲ့ အစိတ်အပိုင်းတွေကို ထပ်ထည့်ပါတယ်။ user ရဲ့ browser သည် frontend ကို load လုပ်ပြီး ၎င်းက API မှတစ်ဆင့် backend နှင့် ပြောဆိုကာ ဒီ backend က user, request, ဒါမှမဟုတ် အချိန်အလိုက် ကွဲပြားနိုင်တဲ့ response တွေကို ဆောက်ဖို့ database ကို ဖတ်ပြီး ရေးသားပေးပါတယ်။
ဒါက login system, personalize လုပ်ထားသော content, user-generated data နှင့် visit တစ်ခုနှင့်တစ်ခုကြား state ကို မှတ်ထားစရာလိုသော အရာတိုင်းရဲ့ နောက်ကွယ်က ပုံသဏ္ဌာန်ပါပဲ။
real system အများစုက ဒီနှစ်ခုထဲက တစ်ခုကို အမြဲတမ်း ရွေးချယ်နေတာ မဟုတ်ပါဘူး — အခု ဆောက်လုပ်နေတဲ့ product ရဲ့ အစိတ်အပိုင်းအတွက် ဘယ်ဟာက ကိုက်ညီလဲဆိုတာကိုသာ ရွေးချယ်နေခြင်းဖြစ်ပြီး ကုမ္ပဏီတစ်ခုတည်းကပင် product တစ်ခုတည်းရဲ့ မတူညီတဲ့ အစိတ်အပိုင်းများအတွက် ပုံစံနှစ်မျိုးလုံးကို သုံးနိုင်ပါတယ်။
STATIC SITE vs FULL-STACK ARCHITECTURE
--------------------------------------
STATIC SITE vs FULL-STACK ARCHITECTURE
------------------------------------------
STATIC WEBSITE ARCHITECTURE
User -> DNS -> CDN -> HTML / CSS / JS / Images
(no backend, no database -- same for everyone)
FULL-STACK ARCHITECTURE
User -> Browser -> Frontend -> Backend/API -> Database
(per-user, per-request, dynamic responses)လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
စီးပွားရေးလုပ်ငန်းငယ်တစ်ခု ပိုင်ရှင်တစ်ဦးက home, about, services, gallery နဲ့ submission တွေကို email ပို့ပေးမယ့် contact form ပါဝင်တဲ့ page ငါးခုပါ website တစ်ခု လိုချင်ပါတယ်။
content က visitor တစ်ဦးချင်းစီအတွက် တစ်ထပ်တည်းဖြစ်ပြီး ဘာမှတွက်ချက်ဖို့ database မလိုအပ်တာကြောင့် ဒါက static website architecture နဲ့ အကောင်းဆုံးကိုက်ညီပါတယ် — DNS က CDN ဆီ route လုပ်ပေးပြီး CDN က ကြိုတင်ဆောက်ထားပြီးသား file တွေကို တိုက်ရိုက် serve လုပ်ပေးကာ hosting cost ကိုလည်း နိမ့်စေပြီး ကမ္ဘာတစ်ဝှမ်းမှာ page load ကို မြန်ဆန်စေပါတယ်။
user တွေ login ဝင်ပြီး ကိုယ်ပိုင် board တွေဖန်တီး, teammate တွေ invite ပြီး ကိုယ့် account နဲ့ ဆိုင်ရာ update တွေ မြင်ရတဲ့ project management tool တစ်ခု ဆောက်နေတဲ့ team တစ်ခုနဲ့ ဒါကို နှိုင်းယှဉ်ကြည့်ပါ။
အဲ့ဒီ content တွေထဲက ဘာမှ static file ထဲကို ကြိုတင်ထည့်ထားလို့ မရပါဘူး၊ ဘာလို့လဲဆိုတော့ user တိုင်းအတွက် ကွဲပြားပြီး အမြဲတမ်း ပြောင်းလဲနေလို့ပါ၊ ဒါကြောင့် ဒါက full-stack architecture လိုအပ်ပါတယ် — backend API နဲ့ ပြောဆိုတဲ့ frontend, request တစ်ခုချင်းစီအလိုက် database ကို ဖတ်ရေးတဲ့ backend။
ပိုရှုပ်ထွေးတဲ့ option ကို default အနေနဲ့ မရွေးခင် မေးခွန်းသုံးခုကို လျင်မြန်စွာ ကျော်ဖြတ်ကြည့်တာက အသုံးဝင်ပါတယ် — ဒါက database တစ်ခုခု လိုအပ်သလား, user account တစ်ဦးချင်းစီ လိုအပ်သလား, ထုတ်ဝေပြီးရင် content က အခြေခံအားဖြင့် ပုံသေဖြစ်သွားသလား။ 'မလို' လို့ဖြေတာ နှစ်ခုသုံးခုရှိရင် static architecture က အနည်းဆုံး အစပျိုးမှတ်အနေနဲ့ လုံလောက်ကြောင်း ညွှန်ပြလေ့ရှိပါတယ်။
အတူတူ စမ်းရေးကြည့်မယ်
function recommendArchitecture({ needsDatabase, needsUserAccounts, contentIsFixed }) {
if (!needsDatabase && !needsUserAccounts && contentIsFixed) {
return "Static Website Architecture";
}
return "Full-Stack Architecture";
}
const projects = [
{ name: "Small business portfolio site", needsDatabase: false, needsUserAccounts: false, contentIsFixed: true },
{ name: "Project management SaaS tool", needsDatabase: true, needsUserAccounts: true, contentIsFixed: false },
{ name: "Company documentation site", needsDatabase: false, needsUserAccounts: false, contentIsFixed: true },
];
for (const project of projects) {
console.log(`${project.name}: ${recommendArchitecture(project)}`);
}ဒါက ဒီအတိုင်း ပရင့်ထုတ်ပါတယ်: Small business portfolio site -> Static Website Architecture, Project management SaaS tool -> Full-Stack Architecture, Company documentation site -> Static Website Architecture။၅ မိနစ် စမ်းကြည့်
သင်သုံးနေတဲ့ website ဒါမှမဟုတ် app ငါးခု စာရင်းလုပ်ပါ။ တစ်ခုစီအတွက် database, user account လိုအပ်မလား, content ပုံသေလားဆိုတာပေါ် မူတည်ပြီး static website architecture ဒါမှမဟုတ် full-stack architecture ဘယ်ဟာနဲ့ ကိုက်ညီလဲ ဆုံးဖြတ်ပါ။
သတိလေးတစ်ချက်
visitor အတွက် ဘယ်တော့မှ မပြောင်းလဲတဲ့ content အတွက်တောင် အလေ့အထအရ full-stack architecture ကို default လုပ်တာ — ဒါက မလိုအပ်တဲ့ server cost နဲ့ complexity ကို တိုးစေပါတယ်။
static architecture မှာ dynamic behavior လုံးဝ မရှိနိုင်ဘူးလို့ ယူဆတာ — client-side JavaScript က static file တွေအပေါ်မှာ interactivity ကို ဆက်ထပ်ထည့်နိုင်ပါသေးတယ်။
Wikipedia — Web application — How the Web Works