Web App နဲ့ App ဘာတွေကွာလဲ

Web App နဲ့ App ဘာတွေကွာလဲလို့မေးရင် Web traffic ကိုလက်ခံနိုင်တာနဲ့ မခံနိုင်တာပဲကွာပါတယ်။ ဒီတော့ web app တခုဖြစ်ဖို့ဆိုရင် အဲဒီ app က Networking လုပ်နိုင်တဲ့ App ဖြစ်ရမယ်။ အနည်းဆုံး TCP socket configuration, HTTP parsing, payload handling စသဖြင့်ပေါ့။ concurrency ပါထည့်၊ ပိုကောင်းတာပေါ့။

ဒါပေမယ့် အဲဒါတွေက developer ကိုယ်တိုင်က ထပ်ခါတလဲလဲ ရေးနေရမှာ မဟုတ်ဘူး။ language level မှာ networking ကောင်းကောင်း support ပါပြီးသား ဥပမာ Go လိုမျိုးဆိုရင် standard library တွေပဲသုံးလို့ဖြစ်တယ်။ compile ပြီးရလာတဲ့ binary ကိုယ်တိုင်က Web server ပဲ။ အဲတော့ socket ဆီ request တခုရောက်လာတာနဲ့ CPU ကို ဘယ် bit sequence တွေ run ခိုင်းမလဲဆိုတာလောက် ရိုးရှင်းတယ်။ Rust လည်းသိပ်မကွာဘူး။ crate တွေသုံး၊ ဒီလိုပဲ ထွက်တာပဲ။

ကိုယ်က တကယ်လို့ app ထဲမှာ web serving နဲ့ပတ်သက်တဲ့ code တွေမပါချင်ဘူးဆိုရင်လည်း ဖြစ်တယ်။ web serving လုပ်နိုင်တဲ့ runtime တော့ရှိရမယ်ပေါ့။ ဥပမာ NodeJS ဆိုပါတော့။ တခုရှိတာက web server အဖြစ် တာဝန်ယူမယ့် အဲဒီ runtime ကတော့ ကိုယ့် app ကိုဘယ်လို run မလဲသိရမယ်။ NodeJS က js runtime ပဲမို့ကိစ္စမရှိ။ တခါတည်း integrate လုပ်ပြီးသား။

တကယ်လို့ runtime က အဲလိုမပါဘူးဆိုရင်လည်း သီးသန့် manager/wrapper တခု ရေးထားလို့ရတယ်။ wrapper ကကိုယ့် app ကိုငုံထားပြီး web traffic ကိုလက်ခံမယ်။ ပြီးရင် traffic ကို handle လုပ်မယ့် code ကိုမှန်အောင်ခေါ်ပေးမယ်ပေါ့။ Java မှာ Tomcat တို့၊ JBoss တို့အလုပ်လုပ်ပုံက အဲဒီလို။ Python လည်းအတူတူပါပဲ။ ကိုယ့် python app ကိုသာ ASGI spec အတိုင်း ရေးထားရင် အပြင်က wrapper ဥပမာ uvicorn ကနေ ကိုယ့်ဆီကို context တွေ payload တွေမှန်အောင် လက်ဆင့်ကမ်းပေးလိမ့်မယ်။

php လို traffic ကိုတောက်လျှောက်စောင့်ဖို့ runtime မရှိဘူးဆိုရင်တောင် အနည်းဆုံးတော့ ဘယ် file ကို run ပေးရမလဲ ပြောပြနိုင်ရင်ပြီးတာပဲ။ nginx တို့၊ apache တို့ကနေ traffic ကိုလက်ခံမယ်။ အဲဒီ server တွေက php interpreter သုံးပြီး လိုအပ်တဲ့ file ကို run မယ်။ std out ကနေပြန်လာတဲ့ ရလဒ်တွေကို client ဆီပြန် dump မယ်ပေါ့။ ပို efficient ဖြစ်ဖို့ နှစ်ခုကြားထဲ manager ထားလိုက်ရင် lifecycle management ပါရသွားမယ်။ php-fpm နဲ့ FastCGI ဆိုတာ အဲသလို အလုပ်လုပ်တဲ့စတိုင်။

Web App တွေက ရိုးရိုး App နဲ့ဘာကွာသလဲမေးရင် ဒါပါပဲ။