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

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


assistant
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 မှာ သတ်မှတ်ထားရပါတယ်။

Recent Article
Social Media app တခုမှာ client ဆီက post အသစ်တခု Create လုပ်ဖို့ request ပို့လိုက်တဲ့အခါ request က raw http အနေနဲ့ Server (Host) ကို ရောက်လာပါတယ်။ Server ရဲ့ Web serving လုပ်နိုင်တဲ့ အစိတ်အပိုင်းတခုခုက ဒီ request ကို ပထမဆုံး လက်ခံရရှိတာဖြစ်တယ်။

တချို့ 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 တွေက အရသာ ၂ မျိုးကွဲသွားပါတယ်။

Laravel

Laravel ဟာ php ecosystem ထဲမှာ အတော်လေး လူသိများတဲ့ framework တခုဖြစ်ပြီးတော့ Laravel သာ မရှိခဲ့ရင် php ကို ဒိုင်နိုဆောတွေနဲ့ တန်းတူ ပြတိုက်မှာပဲ ကြည့်လို့ရတော့မယ်လို့တောင် ဆိုကြပါတယ်။ Python ရဲ့ Django နဲ့ Ruby ရဲ့ ROR တို့လို battery-included framework တခုဖြစ်ပြီး Laravel မှာ တိကျတဲ့ file structure နဲ့ web application တခုရဲ့ အသုံးအများဆုံး feature တွေက အသင့်ပါဝင်ပြီးသား ဖြစ်တယ်။ opinionated framework တခုဖြစ်တဲ့ Laravel က Architecture မှာ ဘယ်လောက် အတိုင်းအတာထိ စွက်ဖက်ထားသလဲ နားလည်ဖို့ လုပ်ကြပါမယ်။

Express JS

ExpressJS ကတော့ Web serving အတွက် လိုအပ်တဲ့ လုပ်ဆောင်ချက်တွေကိုပဲ ပေးနိုင်ဖို့ ရည်ရွယ်ပါတယ်။ Python's Flask နဲ့ Golang ရဲ့ Gin တို့လို lightweight framework တခု ဖြစ်ပြီး feature တွေကို စိတ်တိုင်းကျ configuration လုပ်ခွင့်ပေးထားတဲ့အတွက် လိုချင်တာကို လိုအပ်သလောက်သာ ရေးချင်တဲ့သူတွေအနေနဲ့ ExpressJS ကိုရွေးချယ်ကြပါတယ်။ minimalistic framework တခုဖြစ်တဲ့ Express အနေနဲ့ကော Laravel နဲ့ ဘယ်လိုတွေ ကွာခြားတာလဲ။

Web Server

ပထမဆုံး Web serving component ကစပြောရရင် Laravel ကို သီးသန့် Web Server software တွေဖြစ်တဲ့ Apache, Nginx တို့နဲ့ပဲ အသုံးပြုကြတာ မြင်ရပါလိမ့်မယ်။ ဒါပေမယ့် ဒါက php နဲ့ Web serving လုပ်နိုင်တဲ့ component တွေ ဆောက်လို့မရလို့ မဟုတ်ပါဘူး။ ရလည်းရသလို ရှိလည်း ရှိပါတယ်။ ဒါပေမယ့် မတွင်ကျယ်တာက တဏ္ဍပေါ့။ php က သမိုင်းအစမှာ CGI ဒါမှမဟုတ် php-fpm (fastCGI) တို့ကနေတဆင့် request တွေ process လုပ်နိုင်ဖို့ ရည်ရွယ်ခဲ့တဲ့ scripting language တခုသာဖြစ်လို့ ရှိပြီးသား Web serving functionality ကို ထည့်မဆောက်ခဲ့ဘူး ယူဆရပါတယ်။ သူ့ထက် အတော်လေး နောက်ကျပြီးမှ ထွက်လာခဲ့တဲ့ Go နဲ့ NodeJs တို့မှာဆိုရင်တော့ Http Module တွေကို အသင့် ထည့်ရေးလာကြပြီး သီးသန့် software အပေါ် မှီခိုစရာ မလိုပဲ production-grade web serving capability ကိုပေးနိုင်ကြတာ ဖြစ်တယ်။


Orchestrator

Orchestrator component ကို Laravel မှာ HTTP Kernel အနေနဲ့ မြင်ရပါတယ်။ request-response pipeline တခုလုံးကို တာဝန်ယူ စီမံပေးတဲ့ ဗဟိုချက်အနေနဲ့ တည်ဆောက်ထားပြီး request/response model တည်ဆောက်တာ၊ middleware stack တာနဲ့ route assisting စတဲ့ တာဝန်တွေကို လုပ်ဆောင်ပါတယ်။ Application intelligence ရှိတာဖြစ်လို့ အပိုဆောင်းအနေနဲ့ path နဲ့ query parameter တွေကိုဖတ်ပြီး dynamic routing နဲ့ conditional middleware တွေကိုပါ လုပ်ပေးနိုင်ပါတယ်။

ExpressJS မှာ HTTP Kernel နဲ့ တိုက်ရိုက်နှိုင်းပြစရာ မရှိပေမယ့် App object က Orchestrator ရဲ့ တာဝန်တွေဖြစ်တဲ့ res နဲ့ resp object တွေတည်ဆောက်တာ၊ routing လုပ်တာ အစရှိတဲ့ လုပ်ဆောင်ချက်တွေကို တာဝန်ယူပါတယ်။ ဒါပေမယ့် Application intelligence ရှိတာဖြစ်လို့ အပိုဆောင်းအနေနဲ့ path နဲ့ query parameter တွေကိုဖတ်ပြီး dynamic routing နဲ့ conditional middleware တွေကိုပါ လုပ်ပေးနိုင်ပါတယ်။

ExpressJS မှာ HTTP Kernel နဲ့ တိုက်ရိုက်နှိုင်းပြစရာ မရှိပေမယ့် App object က Orchestrator ရဲ့ တာဝန်တွေဖြစ်တဲ့ res နဲ့ resp object တွေတည်ဆောက်တာ၊ routing လုပ်တာ အစရှိတဲ့ လုပ်ဆောင်ချက်တွေကို တာဝန်ယူပါတယ်။ ဒါပေမယ့် Application intelligence မပါဝင်တဲ့အတွက် Laravel လို feature တွေအသင့်သုံး မရနိုင်ပါဘူး။


Request/Response Model

Laravel ရဲ့ Request နဲ့ Response php object တွေ တည်ဆောက်ဖို့ အသုံးပြုတဲ့ Illuminate\Http က PSR-7 interface အပေါ် အခြေခံထားပြီး PSR-7 ကို အဓိက ဒီဇိုင်းချခဲ့တဲ့သူတွေကတော့ နောက်ထပ် နာမည်ကျော် php framework တခုဖြစ်တဲ့ symfony ရဲ့ developers တွေပဲ ဖြစ်ပါတယ်။

ExpressJS ကို NodeJS အပေါ် တည်ဆောက်ထားပြီး NodeJS ကိုယ်တိုင်ကိုက http module ပါဝင်တဲ့ web serving component တခုဖြစ်လို့ NodeJS အနေနဲ့ raw http တွေကို IncomingMessage နဲ့ ServerResponse Object အဖြစ် တပါတည်း ပြောင်းပေးပြီးသားဖြစ်တယ်။ ဒါပေမယ့် အဲအပေါ်မှာမှ Express က wrapper တွေအုပ်ပြီး res နဲ့ resp object တွေအဖြစ် ထပ်ဆောက်ပါသေးတယ်။


Middleware နဲ့ Handler

Laravel မှာ Middleware နဲ့ Handler က ကွဲပြားတဲ့ အရာ ၂ ခုဖြစ်ပြီး middleware တွေက native construct အနေနဲ့ သီးသန့်ပါဝင်တာဖြစ်တယ်။ ဒီအချက်ကို Http Kernel ရဲ့ http intelligence နဲ့ ပေါင်းစပ်လိုက်တဲ့အခါ Request ရဲ့ path နဲ့ query parameter တွေကို ဖတ်ပြီး dynamic routing လုပ်တာ၊ conditional middleware stack တာမျိုးတွေ လုပ်နိုင်စေပါတယ်။ Handler ကိုလည်း Controller အဖြစ် တွေ့ရပြီး Controller class ထဲမှာ Http verb ဖြစ်တဲ့ Get, Post လိုအပ်ချက်သလို Handler Method တွေရေးထားလို့ရပါတယ်။

ExpressJS မှာတော့ Middleware concept မပါဝင်ပဲ Handler နဲ့ Middleware နှစ်ခုလုံးက Handler တွေအဖြစ်ပဲ ရှိကြတာဖြစ်တယ်။ Http intelligence လည်း မရှိတဲ့အတွက် handler ထဲမှာပဲ candidate မှန်မမှန် စိစစ်ရပြီး path နဲ့ query တွေကို စစ်ဆေးနိုင်မယ့် control flow logic တွေကို ရေးထားကြရပါတယ်။

Laravel ရဲ့ တချို့ middleware တွေက တခါတည်း builtin ပါပြီးဖြစ်တဲ့အတွက် overhead မဖြစ်စေပဲ pipeline အစီအစဥ်ကို ပြင်ရခက်သလို ExpressJS ရဲ့ native middleware မပါတဲ့ အချက်က pipeline ဆောက်ရာမှာ ပိုလွတ်လပ်ခွင့်ရစေနိုင်ပါတယ်။


Routing System

Laravel မှာ api.php ဒါမှမဟုတ် web.php file တွေက route mapper အနေနဲ့ တည်ရှိပါတယ်။ Java EE app တွေရဲ့ multi components routing system နဲ့စာရင် Laravel ရဲ့ နည်းလမ်းက ရိုးရှင်းတာ တွေ့ရပါမယ်။ Handler နဲ့ middleware registration တွေကို တနေရာတည်းမှာ လုပ်ထားနိုင်ပြီး Orchestrator က ဒီဖိုင်ကို ဖတ်ပြီး pipeline တည်ဆောက်ပေးမှာဖြစ်တယ်။

ExpressJS မှာတော့ routing system သီးသန့် မရှိပါဘူး။ ဒါကြောင့် request processing လုပ်တဲ့အခါ အစဥ်အတိုင်း ​ဖြတ်သွားစေပြီး match ဖြစ်တဲ့ Handler (controller) ဆီမှာ req ကို process လုပ်စေပါတယ်။


Opinionated နဲ့ Minimalistic framework တွေက ဒီလိုမျိုး architecture ကိုချဥ်းကပ်တဲ့ပုံစံတင် ကွဲပြားကြတာ မဟုတ်ပါဘူး။ Storage, Session, ORM နဲ့ Query Builder အစရှိတဲ့ web app တခု တည်ဆောက်တဲ့အခါ အသုံးများတဲ့ feature တွေကို ဘယ်အတိုင်းအတာအထိ အသင့်သုံးဖြစ်အောင် လုပ်ထားပေးသလဲဆိုတဲ့နေရာမှာလည်း ကွာခြားကြပါသေးတယ်။ ဥပမာ Python ရဲ့ Sql Alchemy, Php ရဲ့ Eloquent တို့က သက်ဆိုင်ရာ framework တွေနဲ့ integration တခါတည်း ပါပြီးဖြစ်လို့ ecosystem အလိုက် နာမည်ကျော်ကြပါတယ်။


2023 မှာ ဘာကို လေ့လာသင့်လဲ

Laravel, Spring တို့က Ecommerce, Blog, CMS နဲ့ MVC web app တွေကို ခိုင်ခိုင်မာမာ မြန်မြန်ဆန်ဆန် တည်ဆောက်ဖို့ သင့်တော်သလို Microservice နဲ့ Backend system တွေရေးဖို့ဆိုရင် Express, Ktor, Go နဲ့ FastAPI တို့က အများကြီး ပိုသင့်တော်ပါလိမ့်မယ်။ ဒါပေမယ့် မူတည်ပါတယ်။ Facebook က php ကို အများကြီး မှီခိုထားပြီး Netflix က JVM နဲ့ရပ်တည်နေတာ မမေ့သင့်ပါဘူး။ ဒါ​ကြောင့် စိတ်ချမ်းသာတာကို လေ့လာစေချင်ပါတယ်။


What's next?

ကျွန်တော် learning by doing ကိုယုံကြည်ပါတယ်။ Laravel ဖြစ်ဖြစ်၊ Spring ဖြစ်ဖြစ်၊ Express ဖြစ်ဖြစ် ကိုယ်သဘောကျရာကို ရွေးချယ်ပြီးရင် လက်တွေ့ project များများရေးကြည့်ဖို့ တိုက်တွန်းပါတယ်။ ဒါပေမယ့် project ရေးတဲ့အခါ syntax ကိုအလွတ်မကျက်ပဲ component တွေဘယ်လိုပေါင်းစပ် အလုပ်လုပ်နေတယ်ဆိုတာကို အလေးပေး ကြည့်စေလိုပါတယ်။ framework နောက်တခု ကူးပြောင်းတဲ့အခါ အားစိုက်ထုတ်ရ အနည်းဆုံး ဖြစ်စေဖို့အတွက် ကိုယ်သုံးနေတဲ့ Web framework ရဲ့ နောက်ကွယ်က အလုပ်လုပ်ပုံနဲ့ ကျောရိုးဖြစ်တဲ့ Web Technology တွေကို နားလည်ထားဖို့ သိပ်အရေးကြီးပါတယ်။

CodeHub by Harry Yan