Modern Frameworks & Monolith
Modern Frameworks = Modern Cars
Section titled “Modern Frameworks = Modern Cars”Tesla ကားတစ်စီးဟာ အပြင်ကကြည့်ရင် ကားတစ်စီးတည်း (One Unit) ပါပဲ။ ဒါပေမဲ့ အတွင်းပိုင်းကို ဖြုတ်ကြည့်လိုက်ရင် Battery Module, Motor Module, AI Module ဆိုပြီး အပိုင်းလေးတွေ သီးခြားစီ စနစ်တကျ ဖွဲ့စည်းထားပါတယ်။
-
Next.js / Remix: Page တွေ၊ Component တွေကို ဖိုင်တွေ သီးခြားခွဲပြီး ရေးထားပေမယ့်၊ နောက်ဆုံး Deploy လုပ်လိုက်ရင် ဆာဗာ (Server) တစ်လုံးတည်း (သို့မဟုတ် Lambda Function တစ်စု) အနေနဲ့ပဲ တက်သွားပါတယ်။ ဒါဟာ Monolith ပါပဲ။ ဒါပေမဲ့ အရမ်း စနစ်ကျတဲ့၊ အပိုင်းလေးတွေ သေသေချာချာ ခွဲထားတဲ့ Monolith မျိုးပါ။
-
Angular: သူ့ရဲ့ Module System (NgModules) နဲ့ Feature တွေကို သီးခြားစီ ခွဲထုတ်ထားပါတယ်။ ဒါပေမဲ့ နောက်ဆုံး Build လုပ်လိုက်တဲ့အခါမှာတော့
main.jsလို့ခေါ်တဲ့ Bundle ဖိုင်တစ်ခုတည်းပဲ ထွက်လာပါတယ်။ ဒါလည်း Monolith ပါပဲ။
ဘယ်အချိန်မှာ Monolith မသုံးသင့်ဘူးလဲ? (Micro-Frontends သုံးသင့်ချိန်)
Section titled “ဘယ်အချိန်မှာ Monolith မသုံးသင့်ဘူးလဲ? (Micro-Frontends သုံးသင့်ချိန်)”Tesla ကားတစ်စီး ဝယ်စီးတာက လူအများစုအတွက် အဆင်ပြေပါတယ်။ ဒါပေမဲ့ အောက်ပါ အခြေအနေမျိုးတွေ ရောက်လာရင်တော့ Monolith နဲ့ အဆင်မပြေနိုင်တော့ပါဘူး။
-
Team အရွယ်အစား အရမ်းကြီးလာတဲ့အခါ: Developer အယောက် ၁၀၀ ကျော်လောက် ရှိလာပြီး၊ Team တစ်ခုချင်းစီက သီးခြား Feature တွေကို တာဝန်ယူလာရတဲ့အခါမျိုးပါ။ (ဥပမာ - Checkout Team သီးသန့်, Search Team သီးသန့်, User Profile Team သီးသန့် စသဖြင့်)။
-
Independent Deployment လိုအပ်တဲ့အခါ: Checkout Team က သူတို့ Feature ကို ပြင်လိုက်တာနဲ့၊ Search Team က ရေးထားတဲ့ Code တွေကိုပါ လိုက်ပြီး ပြန် Build ရတာ၊ Deploy လုပ်ရတာမျိုး မလုပ်ချင်တော့တဲ့အခါ။ (ကိုယ့် Team နဲ့ ကိုယ် သီးခြားစီ တင်ချင်တဲ့အခါ)။
-
Technology Diversity လိုချင်တဲ့အခါ: အရင်က ရေးခဲ့တဲ့ Legacy Code တွေကို Angular နဲ့ပဲ ဆက်ထားပြီး၊ Feature အသစ်တွေကိုကျတော့ React လိုမျိုး နည်းပညာအသစ်နဲ့ ရေးချင်တဲ့အခါမျိုးပါ။ (နည်းပညာ အမျိုးမျိုး ရောသုံးချင်တဲ့အခါ)။