user
web framework က Backbone Components တွေရဲ့ high level architecture ကို အကျယ်ရှင်းပြပေးပါ


assistant
Web Framework တခုရဲ့ architecture ကို High level ကြည့်မယ်ဆိုရင် Orchestrator, Request/Response Model, Routing System, Handler, Middleware ဆိုပြီး အဓိက ၅ ခု ရှိပါတယ်။

Orchestrator ရဲ့ တာဝန်က request-response cycle တခုလုံးကို စီမံ manage လုပ်ပေးဖို့ဖြစ်တယ်။

Request နဲ့ Response Model တွေက raw http တွေကို Web Program က နားလည်မယ့် object တွေအဖြစ် ပြောင်းယူထားတဲ့ model တွေဖြစ်ပါတယ်။ ပြောင်းလိုက်တဲ့ Request Object မှာ မူလ raw http ထဲပါလာတဲ့ header, body စတာတွေကို state အနေနဲ့ ပြန်ရယူနိုင်သလို လိုအပ်တဲ့ behavior တွေကိုပါ တပါတည်း ထည့်ဆောက်ပေးလိုက်ပါတယ်။

Handler တွေက business logic နဲ့ဆက်နွယ်တဲ့ လုပ်ဆောင်ချက်တွေကို ကိုင်ထားပြီး Middlware တွေကတော့ business logic နဲ့ တိုက်ရိုက် မပတ်သက်တဲ့ လုပ်ဆောင်ချက်တွေကို တာဝန်ယူကြတယ်။ Shopping mall တခုအနေနဲ့ တွေးကြည့်မယ်ဆိုရင် ပစ္စည်းတင်တဲ့စင်၊ စျေးခြင်း၊ ငွေရှင်းကောင်တာ၊ အရောင်းဝန်ထမ်း စတာတွေက business logic တွေဖြစ်ပြီး ဝင်ပေါက်မှာ လုံခြုံရေး စစ်တာနဲ့ mall ထဲက cctv တွေကိုတော့ စျေးဝယ်ရာမှာ တိုက်ရိုက်မပတ်သက်တဲ့ middleware တွေလို့ တွေးကြည့်နိုင်ပါတယ်။ 

client ဆီက Request ရောက်လာတဲ့အခါ ဘယ် url နဲ့ ဘယ်အခြေအနေတွေမှာဆိုရင် အဲဒီ Request ကို ဘယ် Handler ဒါမှမဟုတ် ဘယ် Middleware တွေက process လုပ်စေချင်သလဲဆိုတာကိုတော့ Routing system မှာ သတ်မှတ်ထားရပါတယ်။

တချို့ language တွေ ဥပမာ Go ဆိုရင် native ပါတဲ့ net/http module က Web Serving လုပ်နိုင်ပြီး NodeJS ဆိုရင်လည်း Web serving လုပ်နိုင်တဲ့ JavaScript's runtime ဖြစ်တယ်။ ဒါပေမယ့် php လိုမျိုး runtime ကော langauge ကောမှာ လုံလောက်တဲ့ Web serving capability မရှိဘူးဆိုရင်လည်း Apache (httpd) ဒါမှမဟုတ် Nginx တို့လို သီးသန့် Web server software တွေကို ဆင်ထားနိုင်ပါတယ်။ Java EE လို servlet နည်းပညာကို အခြေခံတဲ့ program တွေမှာဆိုရင်တော့ Tomcat, JBoss တို့လို Servlet container တွေကို တဆင့်ခံ အသုံးပြုပါတယ်။

Web server က raw http ကို လက်ဆင့်ကမ်းလိုက်တဲ့အခါ Program ရဲ့ Orchestrator က http string ကို Request Object အဖြစ်ပြောင်းလိုက်ပါတယ်။ 

ဒါပြီးရင် Orchestrator အနေနဲ့ Routing system ကိုဖတ်ပြီး register လုပ်ထားတဲ့ middleware တွေကိုရှာပါတယ်။ လိုအပ်တဲ့ middleware တွေက memory ထဲမရှိသေးဘူးဆိုရင် စဆောက်ပြီး စောစောက Request object ကို တခုချင်း process လုပ်စေပါတယ်။

Social Media App မှာဆိုရင် req တဲ့သူက Logged in ဝင်ထားတဲ့ User ဟုတ်မဟုတ် စစ်ဆေးတာ နောက်ပြီး User ရဲ့ location, session နဲ့ request ရောက်လာတဲ့ အချိန်ကို မှတ်တာ စတဲ့ business logic နဲ့ တိုက်ရိုက်မပတ်သက်တဲ့ Authentication, Session, Logging middleware တခုပြီး တခု လုပ်ကြပါတယ်။ registered ထားတဲ့ middleware တွေ ကုန်ပြီဆိုရင် Handler ဆီ forward လုပ်ပေးလိုက်ပါတယ်။

Handler က ဒီနေရာမှာ PostHandler ဖြစ်ပြီး Post တင်ခွင့်ရှိတဲ့သူ ဟုတ်မဟုတ် စစ်ဆေးတာ၊ Post မှာပါတဲ့ စာလုံးအရေအတွက် ကန့်သတ်ချက်ကို စစ်တာ၊ Post ကို Database ထဲ ထည့်သိမ်းတာ စတဲ့ business logic တွေကို ဆက်လုပ်ပါလိမ့်မယ်။ ဒါပြီးရင် သင့်တော်တဲ့ အချက်အလက်တွေ ဖြည့်ပြီး response model ကို ပြန်ပို့လိုက်ပါတယ်။

Response Model ကိုရတဲ့အခါ Orchestrator က Routing System ထဲမှာ response အတွက် register လုပ်ထားတဲ့ middleware တွေ ရှိမရှိ ထပ်ရှာပါတယ်။ မှတ်စရာ ရှိတာက request နဲ့ response အတွက် သတ်မှတ်ထားတဲ့ middleware တွေက ခေါက်ချိုးညီ (symmetric) ဖြစ်ဖို့ မလိုအပ်ပါဘူး။ တကယ်လို့ Routing system ထဲ register ထားတာ ရှိတယ်ဆိုရင် Response Model ကို လိုအပ်သလို process လုပ်စေပါတယ်။

အမှားအယွင်းမရှိ ပြီးသွားတဲ့အခါ orchestrator အနေနဲ့ Response Model ကို raw http အ​ဖြစ်ပြန်ပြောင်းပါတယ်။ raw http ကို Web server ဆီပြန်ပို့လိုက်ပြီး Web server က client ဆီ response ပြန်လိုက်တဲ့အခါ Request Response cycle တခုပြီးဆုံးပါတယ်။

ဒီ High level architecture ကို web framework တွေ ချဥ်းကပ်တည်ဆောက်ပုံ မတူကြပါဘူး။ ဘယ်အတိုင်းအတာထိ အသေးစိတ် ပေးထားသလဲဆိုတဲ့အပေါ် မူတည်ပြီး Web framework တွေက အရသာ ၂ မျိုးကွဲသွားပါတယ်။