မာတိကာ[ဖျောက်][ရှိုး]
- micro front-end ဗိသုကာ မိတ်ဆက်
Micro frontend ၏အားသာချက်များ +-
- လျင်မြန်စွာ ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရအဖွဲ့များတွင် ဖွံ့ဖြိုးတိုးတက်မှု
- တစ်ဦးချင်း Micro Frontends ၏ ပိုသေးငယ်သော Codebases များသည် Cleaner Code သို့ ဦးတည်သည်။
- Loose Coupling ကြောင့် အက်ပ်တည်ငြိမ်မှုကို မြှင့်တင်ထားသည်။
- တစ်ဦးချင်းအင်္ဂါရပ်များကို စမ်းသပ်ခြင်းသည် ပိုမိုရိုးရှင်းပါသည်။
- အစုအဝေးအရွယ်အစားကို လျှော့ချခြင်းဖြင့် စာမျက်နှာ Load ကို ပိုမိုမြန်ဆန်စေသည်။
- နည်းပညာလွတ်လပ်ရေး
- ကောက်ချက်
Microservices ၏ စိတ်ကူးသည် မကြာသေးမီက အာရုံစိုက်မှုများစွာရရှိခဲ့ပြီး ကြီးမားသော monolithic backends များကို ဖယ်ရှားရန်အတွက် ကုမ္ပဏီများစွာက ၎င်းကို အသုံးပြုနေပါသည်။
ဝဘ်အက်ပ်များ၏ ဆာဗာဘက်ခြမ်းကို တည်ဆောက်ရာတွင် ဤဖြန့်ဝေမှုပုံစံသည် သုတေသနနှင့် လုပ်ဆောင်မှုဆိုင်ရာ သတ်မှတ်ချက်များတွင် ပို၍ သို့မဟုတ် နည်းပါးသော်လည်း တူညီသောလမ်းကြောင်းကို ရှေ့တန်းသို့ သွားရန်မှာ စီးပွားရေးလုပ်ငန်းများစွာအတွက် စိန်ခေါ်မှုတစ်ခု ဖြစ်နေဆဲဖြစ်သည်။
၎င်း၏အနီးကပ်မှီခိုမှုကြောင့်၊ client-side monolith သည် ပုံမှန်အားဖြင့် အင်္ဂါရပ်အသစ်များကို ပေါင်းစည်းရန်၊ နည်းပညာအသစ်များနှင့် အစိတ်အပိုင်းတစ်ခုချင်းစီကို အတိုင်းအတာတစ်ခုအထိ ခက်ခဲစေသည်။
ဤအရာများနှင့် အခြားစိန်ခေါ်မှုများသည် မိုက်ခရိုဝန်ဆောင်မှုများကို အသုံးပြု၍ စုံစမ်းစစ်ဆေးရန် Frontend developer များအား လှုံ့ဆော်ပေးခဲ့သည်။
ရလဒ်အနေဖြင့်၊ ဝဘ်ဆိုက်များနှင့် ဝဘ်အခြေခံအက်ပ်လီကေးရှင်းများ၏ ရှေ့ဆုံးအလွှာကို ဖန်တီးရန်အတွက် micro frontend ဟုလူသိများသော အသစ်စက်စက် ဗိသုကာဗျူဟာကို တီထွင်ခဲ့သည်။
ဝေါဟာရကို 2016 ခုနှစ်တွင် စတင်အသုံးပြုခဲ့ပြီး ထိုအချိန်မှစ၍ ၎င်းသည် ကောင်းမွန်သောအကြောင်းပြချက်အတွက် အာရုံစိုက်မှုများစွာရရှိခဲ့သည်။
ဤဆောင်းပါးတွင် micro frontends သည် အဘယ်အရာဖြစ်သည်နှင့် ၎င်းတို့ဖြေရှင်းသည့် ပြဿနာများကို ယေဘူယျနားလည်သဘောပေါက်မည်ဖြစ်သည်။ ၎င်းသည် အလုပ်ဖြစ်သည့်အပြင် ကောင်းကျိုးနှင့် ဆိုးကျိုးများပါရှိသည်။
micro front-end ဗိသုကာ မိတ်ဆက်
micro-frontend ဗိသုကာလက်ရာဟုခေါ်သော ရှေ့ဆုံးဖွံ့ဖြိုးတိုးတက်မှု၏ ခေတ်ပြိုင်နည်းလမ်းကို ပိုင်းခြားထားသည်။ ဝဘ်အပလီကေးရှင်း သေးငယ်သော၊ သီးခြားအစိတ်အပိုင်းများအဖြစ်သို့။
အသုံးပြုသူအတွက်၊ ဤအစိတ်အပိုင်းများကို သီးခြားလွတ်လပ်စွာတည်ဆောက်ပြီးနောက် ပေါင်းစည်းထားလျှင်ပင် ယူနစ်တစ်ခုအဖြစ် ပေါ်လာပါသည်။
အွန်လိုင်းဖြေရှင်းချက်များ၏ micro frontends သည် client ဘက်မှမဟုတ်ဘဲ server side နှင့်သက်ဆိုင်သည့် ခြားနားချက်နှင့်အတူ၊ ၎င်းတို့ကိုအခြေခံထားသော ကျိုးကြောင်းဆီလျော်မှုသည် microservices နှင့် ထပ်တူပါသည်။
ဆန်းပြားသော web-based ထုတ်ကုန်များကို ဖန်တီးခြင်းသည် micro frontend ချဉ်းကပ်မှုကို အသုံးပြုသည့်အခါ အထိရောက်ဆုံးဖြစ်သည်။
Micro frontends များသည် သမားရိုးကျ front-end monolith နှင့် ဆန့်ကျင်ပြီး အဖွဲ့များစွာကို ဆော့ဖ်ဝဲလ်ပရောဂျက်အမျိုးမျိုးတွင် သီးခြားပူးပေါင်းလုပ်ဆောင်နိုင်စေပါသည်။
ပရိုဂရမ်မာများသည် ဤဗိသုကာဒီဇိုင်းကို အသုံးပြု၍ ဝဘ်အက်ပ်များကို ပိုမိုလျင်မြန်စွာ ဖန်တီးနိုင်သည် ။
ရိုးရိုးရှင်းရှင်းပြောရလျှင် micro frontend တစ်ခုစီသည် ဝဘ်စာမျက်နှာ၏ ထူးခြားသောအစိတ်အပိုင်းတစ်ခုအတွက် ကုဒ်အပိုင်းတစ်ခုမျှသာဖြစ်သည်။
ဤအင်္ဂါရပ်များကို သီးခြားအဖွဲ့များက ထိန်းချုပ်ထားပြီး၊ တစ်ခုစီသည် လုပ်ငန်းနယ်ပယ် သို့မဟုတ် ရည်မှန်းချက်အတွက် အထူးပြုပါသည်။
Monolithic vs Microservices နှင့် Micro frontend ဗိသုကာ
နေရာပြောင်းဖို့စဉ်းစားပါ။ အရာအားလုံးကို ကျွမ်းကျင်စွာ တံဆိပ်ကပ်ထားသော သေတ္တာငယ်များအဖြစ် စုစည်းပြီး တစ်ခုချင်းစီအလိုက် နေရာပြောင်းခြင်း သို့မဟုတ် ဝန်ထမ်းတစ်ခုလုံးကို ကြီးမားသောသေတ္တာတစ်ခုထဲသို့ ထုပ်ပိုးပြီး တည်နေရာအသစ်သို့ ပို့ဆောင်ရန် သင့်အတွက် လွယ်ကူမည်လား။
ရှင်းရှင်းလင်းလင်း ဖြေရှင်းချက်က အဲဒီမှာ။
ဤဥပမာနှစ်ခုသည် ထူးခြားသောဝဘ်အက်ပ်ဗိသုကာလက်ရာများ၊ monoliths နှင့် microservices (micro frontends ဟုလည်းသိကြသည်) နှိုင်းယှဉ်ပါသည်။
Monolithic ဗိသုကာ
ပြီးပြည့်စုံသော အပလီကေးရှင်းတစ်ခုကို တစ်ခုတည်း၊ ပေါင်းစပ်ဖွဲ့စည်းမှုတစ်ခုအဖြစ် ဖန်တီးလိုက်သောအခါတွင် သင်သည် “ကောင်းသောနေ့ရက်များ” ကို မှတ်မိနိုင်ပေမည်။ ထိုနည်းလမ်းကို ကျောက်တုံးကြီးတစ်ခုအတွက် ရှေးအသုံးအနှုန်းဖြစ်သည့် monolith ဟုခေါ်သည်။
ဒါကသဘာဝကျတယ်။
Monolithic စနစ်များတွင် အပြန်အလှန်မှီခိုသော ဒြပ်စင်များရှိသည်။ ထို့ကြောင့် သင်သည် တစ်ခုခုကို ပြုပြင်မွမ်းမံရန် သို့မဟုတ် အင်္ဂါရပ်အသစ်တစ်ခုကို ထည့်လိုပါက၊ စနစ်တစ်ခုလုံး ပျက်သွားနိုင်သည်။
အသုံးမပြုတော့သော်လည်း၊ ရံဖန်ရံခါ ရှိနေသေးသည်။ ဟုတ်တယ်၊ မင်းရဲ့လက်ရှိအသုံးအနှုန်းကို ငါတို့သိတယ်။
ကုဒ်ဘေ့စ်၏ သဘောတရားကို မတူညီသော အစိတ်အပိုင်း နှစ်ခုအဖြစ် ပိုင်းခြားခြင်း — Frontend (Client-side) နှင့် Backend (server-side) — နည်းပညာသစ်များ တီထွင်ပြီး ဆော့ဖ်ဝဲလ် ထုတ်ကုန်များသည် ပိုမိုရှုပ်ထွေးလာသဖြင့် ရှောင်လွှဲ၍မရဖြစ်လာသည်။
အသုံးပြုသူနှင့် ထိတွေ့ဆက်ဆံသည့် တင်ပြမှုအလွှာကြားတွင် ပူပန်မှုများနှင့် နောက်ခံတွင် ဖြစ်ပျက်နေသမျှတို့ကို ခွဲခြားသတ်မှတ်သည့် လုပ်ဆောင်ချက်၏ ရေပန်းအစားဆုံးနည်းလမ်းမှာ ယခုဖြစ်သည်။
ဆော့ဖ်ဝဲလ်အင်ဂျင်နီယာအဖွဲ့နှစ်ဖွဲ့ လိုအပ်ပြီး၊ ရှေ့ဆုံးအဖွဲ့သည် အမြင်အာရုံအစိတ်အပိုင်းများကို တည်ဆောက်ကာ ဝဘ်ဝန်ဆောင်မှုများ၊ စီးပွားရေးယုတ္တိဗေဒ၊ ဒေတာဝင်ရောက်မှု၊ ပေါင်းစည်းမှုစသည်ဖြင့် တည်ဆောက်နေပါသည်။
မည်သို့ပင်ဆိုစေကာမူ ဤကွဲပြားနေသော်လည်း၊ ဤနည်းဗျူဟာသည် သဘာဝအားဖြင့် monolithic ဖြစ်နေဆဲဖြစ်သည်။
အဓိက ပြောင်းလဲမှုမှာ ယခု ကျွန်ုပ်တို့တွင် ကြီးမားသော အပလီကေးရှင်းတစ်ခုအစား ရှေ့တန်းနှင့် နောက်ကွယ်တွင် ကြီးမားသော ကုဒ်တုံးနှစ်ခုရှိသည်။ Monolithic ဗိသုကာလက်ရာများသည် ကြောက်စရာကောင်းရန် မလိုအပ်ပါ။ ၎င်းတို့တွင် အကျိုးကျေးဇူး အနည်းငယ်ရှိသည်။
- အရင်းအမြစ် codebase တစ်ခုတည်းနှင့် အလွန်ရိုးရှင်းသော ဒီဇိုင်းဖြင့် အသေးစား အပလီကေးရှင်းများအတွက် ရိုးရှင်းပြီး လျင်မြန်သော ဖွံ့ဖြိုးတိုးတက်မှု။
- စမ်းသပ်ခြင်းနှင့် အမှားရှာပြင်ခြင်းများသည် ကုဒ်အားလုံးသည် တည်နေရာတစ်ခုတည်းတွင် ရှိနေသောကြောင့်၊ အဖွဲ့တစ်ဖွဲ့သည် တောင်းဆိုချက်တစ်ခု၏စီးဆင်းမှုကို ခြေရာခံပြီး အမှားအယွင်းများကို ရှာဖွေဖော်ထုတ်ရန် ပိုမိုလွယ်ကူစေသောကြောင့်၊
- အက်ပလီကေးရှင်းကို တီထွင်ရာတွင် အစောပိုင်းတွင်၊ အင်္ဂါရပ်အသစ်များမထည့်သွင်းမချင်း အခြေခံအဆောက်အအုံကုန်ကျစရိတ်နှင့် ဖွံ့ဖြိုးရေးကုန်ကျစရိတ်များ မဖြစ်ပေါ်သောကြောင့် ကုန်ကျစရိတ်များ သက်သာပါသည်။
ဤနည်းဗျူဟာ၏ အားနည်းချက်များကို ထင်ဟပ်စေပါသည်။
- ကန့်သတ်ထားသည့် ဖြန့်ကျက်ပြောင်းလွယ်ပြင်လွယ် - ပရောဂျက်တွင် လုပ်ဆောင်နေသည့် လက်တစ်ဆုပ်စာမျှသာ ရှိလျှင် အဖွဲ့များသည် ကုဒ်ကို အပ်ဒိတ်လုပ်တိုင်း အသစ်အသုံးပြုရန် လိုအပ်ပါသည်။
- ပရောဂျက်တစ်ခုလုံးမဟုတ်ပါက သိသာထင်ရှားသောအပိုင်းကို ပြန်လည်ရေးသားရန် လိုအပ်သောကြောင့် နည်းပညာအသစ်များကို ကျင့်သုံးခြင်းသည် စိန်ခေါ်မှုဖြစ်သည်။
- developer အရေအတွက်များလာသောအခါ၊ ကုဒ်စနစ်တစ်ခုသည် အနီးကပ်ချိတ်ဆက်မှု၊ ရှုပ်ထွေးလာပြီး စီမံခန့်ခွဲရန်နှင့် နားလည်ရန်ခက်ခဲလာသည်။
- အဖွဲ့အစည်းဆိုင်ရာပြဿနာများ – အဖွဲ့သားတစ်ဦးစီသည် တူညီသောစာကြည့်တိုက်များ၏ဗားရှင်းကိုအသုံးပြုပြီး အသင်းများစွာသည် monolithic ပရောဂျက်ကိုလုပ်ဆောင်နေပါက အပြောင်းအလဲများကို သတင်းပို့ရပါမည်။
- ချဲ့ထွင်နိုင်မှုနှင့် ပတ်သက်၍ စိုးရိမ်မှုများ - ပရောဂျက်၏ အစိတ်အပိုင်းများ အပြန်အလှန် ချိတ်ဆက်နေသောကြောင့် ၎င်းတို့ကို သီးခြားစီ ချဲ့ထွင်ခြင်းသည် သိသာထင်ရှားသော အချိန်ကုန်ခြင်းနှင့် ပိုမိုမြင့်မားသော အသုံးစရိတ်များကို ဖြစ်ပေါ်စေသည့် အခက်အခဲများကို တင်ပြပါသည်။
- ပရောဂျက်၏ ရှုပ်ထွေးသော ယုတ္တိဗေဒသည် အဖွဲ့၀င်အသစ်များအတွက် နားလည်ရန်ခက်ခဲနိုင်သည်၊ အထူးသဖြင့် ၎င်းတွင် မူလလုပ်ကိုင်ခဲ့သော အင်ဂျင်နီယာများ အလုပ်မရှိတော့ပါက၊
microservices များနှင့် ၎င်းတို့၏ရင်းနှီးသောဆွေမျိုးများနှင့် micro frontends များသည် monolithic စနစ်များဖြင့် အဓိကပြဿနာများကို ဖြေရှင်းပေးခဲ့သည်။
Microservices ဗိသုကာ
microservices ဟုခေါ်သော ဗိသုကာနည်းလမ်းသည် အပလီကေးရှင်းနောက်ကွယ်တွင် ပါဝင်သည့် ပေါ့လျော့စွာချိတ်ဆက်ထားသော သေးငယ်သော အစိတ်အပိုင်းများ သို့မဟုတ် ဝန်ဆောင်မှုများကို သီးခြားဖန်တီးနိုင်စေပါသည်။
ဝန်ဆောင်မှုတိုင်းတွင် ၎င်း၏ကိုယ်ပိုင် codebase၊ CI/CD ပိုက်လိုင်းများ၊ DevOps လုပ်ထုံးလုပ်နည်းများနှင့် ၎င်းတို့ကို လုပ်ဆောင်ရန်အတွက် လုပ်ငန်းစဉ်များရှိသည်။
အထက်ပုံတွင်ကြည့်ခြင်းဖြင့် monolithic backend အဖွဲ့အား သီးခြားအဖွဲ့များခွဲထားသည်ကို သင်တွေ့မြင်နိုင်ပါသည်။
တစ်ခုချင်းစီသည် အပလီကေးရှင်း၏ မတူညီသောရှုထောင့်တစ်ခု (ဥပမာ ထုတ်ကုန်ဝန်ဆောင်မှု၊ ရှာဖွေရေးဝန်ဆောင်မှုနှင့် ငွေပေးချေမှုဝန်ဆောင်မှု) ကို တစ်ဦးချင်းအာရုံစိုက်သည်။
ဝန်ဆောင်မှုများအကြား ဆက်သွယ်ရေးသည် တစ်ပြိုင်နက်တည်း တောင်းဆိုမှု-ပြန်ကြားမှုပုံစံများကို အသုံးပြုသည့် ပေါ့ပါးသော REST API ပရိုတိုကောကဲ့သို့သော APIs များဟု လူသိများသော တည်ထောင်ထားသော ပရိုတိုကောများမှတစ်ဆင့် ဖြစ်ပေါ်လာသည်။
အခြားရွေးချယ်စရာမှာ ဆက်သွယ်ရေးဖွဲ့စည်းပုံနှင့် ဖြစ်ရပ်များကို ထုတ်ဝေခြင်း/စာရင်းသွင်းခြင်းတို့ကို ပေးဆောင်သည့် Kafka ကဲ့သို့သော ဆော့ဖ်ဝဲကို အသုံးပြု၍ အညီအမျှ ဆက်သွယ်ရေးကို အသုံးပြုရန်ဖြစ်သည်။
Microservices များသည် frontend (BFF) ဝန်ဆောင်မှုအတွက် backend သို့မဟုတ် ကွန်ရက်မှတဆင့် API Gateway မှတဆင့် frontend နှင့် ပေါင်းစပ်ထားသည်။ BFF သည် client တစ်ခုစီအတွက် စိတ်ကြိုက် API ကို ပေးဆောင်သော်လည်း API Gateways သည် microservices အစုအဝေးအတွက် တစ်ခုတည်းသော ဝင်ရောက်ခွင့်ကို ပေးပါသည်။
သို့သော် ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရှိသော နောက်ခံအစိတ်အပိုင်းများနှင့် ၎င်းတို့ပေးဆောင်သည့် အားသာချက်များအားလုံးတွင်ပင်၊ ရှေ့တန်းသည် မော်နီယံအဖြစ်ရှိနေဆဲဖြစ်သည်။
ထို့ကြောင့်၊ ဤနေရာတွင် micro frontends များသည် အသုံးဝင်သည်။
Micro frontends ဗိသုကာ
အဖွဲ့အများအပြားက ချိတ်ဆက်ထားသော အစိတ်အပိုင်းများကို လျော့ရဲရဲဖြစ်စေသော ချိတ်ဆက်ထားသော အစိတ်အပိုင်းများကို မိုက်ခရိုဝန်ဆောင်မှုများနှင့် ဆင်တူသည်၊ micro frontend ဗိသုကာသည် အယူအဆကို ဘရောင်ဇာတွင် အသုံးချသည်။
ဤဝဘ်အပလီကေးရှင်းအသုံးပြုသူ အင်တာဖေ့စ်များသည် အနည်းငယ်သော ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရှိသော အစိတ်အပိုင်းများပါ၀င်သည့် ဤဖွဲ့စည်းပုံအတိုင်း လိုက်နာပါသည်။
အဖွဲ့များကို အထူးကျွမ်းကျင်မှု သို့မဟုတ် နည်းပညာထက် သုံးစွဲသူလိုအပ်ချက် သို့မဟုတ် အသုံးပြုမှုကိစ္စများတွင်လည်း ဖန်တီးထားသည်။
ထို့ကြောင့်၊ အဖွဲ့များသည် microservices နှင့် micro frontend ပရောဂျက်များတွင်ပါ၀င်ပါသည်။
- ဒေါင်လိုက် လှီးဖြတ်ထားသည် — frontend developer များ၊ data experts ၊ backend engineers ၊ QA engineers စသည်တို့လည်း တူညီသော ပရောဂျက်တွင် လုပ်ဆောင်နေသောကြောင့် ၎င်းတို့သည် ၎င်းတို့၏ အင်္ဂါရပ်များကို ဖန်တီးပါသည်။ user interface ကို ဒေတာဘေ့စ်များသို့; နှင့်
- လုပ်ငန်းခွင်သုံး - အဖွဲ့၀င်တစ်ဦးစီသည် အဖွဲ့အတွက် ၎င်းတို့၏ကျွမ်းကျင်မှုများကို ပံ့ပိုးပေးသည်။
အဖွဲ့များသည် ၎င်းတို့၏ လုပ်ငန်းအမျိုးအစားအလိုက် အသင့်တော်ဆုံး နည်းပညာအစုကိုလည်း ရွေးချယ်နိုင်သည်။
အဖွဲ့တစ်ဖွဲ့သည် ၎င်း၏အပိုင်းအစကို အစီအစဉ်ဆွဲရန် React ကို အသုံးပြုနိုင်သည်။ အခြားအဖွဲ့သည် Angular ဗားရှင်းအသစ်ကို ဖန်တီးသည်။ Vue.js သည် ဥပမာတစ်ခုဖြစ်သည်။
ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များသည် ပုံမှန်အားဖြင့် monoliths များနှင့် ပြဿနာများကို ဖြေရှင်းရန်အတွက် ဆက်စပ် microservices များနှင့် တွဲဖက်အသုံးပြုပါသည်။ နည်းဗျူဟာသည် အောက်ပါ အားသာချက်များကို ပေးဆောင်သည်။
- နည်းပညာလွတ်လပ်ခွင့်- Frontend အင်ဂျင်နီယာများသည် ကုမ္ပဏီ၏လိုအပ်ချက်ပေါ်မူတည်၍ အခြား JavaScript မူဘောင်များ၊ runtime ပတ်၀န်းကျင်နှင့် နည်းပညာအစုအဝေးများကို ရွေးချယ်နိုင်ပါသည်။ ခေတ်မမီတော့သော ဗိသုကာလက်ရာအပေါ်တွင်၊ ဘောင်အသစ်တစ်ခုကို အသုံးပြုနိုင်သည်။
- Micro Frontend တစ်ခုစီသည် ကိုယ်တိုင်ပါ၀င်ပြီး သီးခြားစီ တီထွင်နိုင်ခြင်း၊ စမ်းသပ်ခြင်း၊ အသုံးပြုခြင်းနှင့် အဆင့်မြှင့်တင်ခြင်းများ ပြုလုပ်နိုင်သောကြောင့် ပိုမိုပြောင်းလွယ်ပြင်လွယ်ဖြစ်နိုင်သည်။ ရလဒ်အနေဖြင့်၊ အဖွဲ့တစ်ဖွဲ့သည် အင်္ဂါရပ်တစ်ခုတွင် လုပ်ဆောင်နေပြီး ချွတ်ယွင်းချက်တစ်ခုကို တွန်းလှန်ပြီး အခြားအဖွဲ့တစ်ဖွဲ့သည် ၎င်း၏ကိုယ်ပိုင်အင်္ဂါရပ်ကို ထည့်သွင်းရမည်ဆိုပါက၊ ၎င်းတို့သည် ၎င်းတို့၏တာဝန်ကို ပြီးမြောက်စေရန် ပထမဆုံးအဖွဲ့အား စောင့်ဆိုင်းနေရန် မလိုအပ်ပါ။
- ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရအဖွဲ့များနှင့် စနစ်များ- ထုတ်ကုန်အဖွဲ့တစ်ခုစီနှင့် အကျိုးဆက်အနေဖြင့် အင်္ဂါရပ်တစ်ခုစီသည် အနီးနားရှိ အစိတ်အပိုင်းများကို မရရှိနိုင်သည့်အခါတွင်ပင် ၎င်းကို ဆက်လက်လုပ်ဆောင်နိုင်စေသည့် အခြားအပေါ်မှီခိုမှုအနည်းငယ်ဖြင့် လုပ်ဆောင်နိုင်သည်။
- များစွာသော၊ ပိုသေးငယ်သော codebases- micro frontend တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်၊ ပိုမိုစီမံခန့်ခွဲနိုင်သော၊ သေးငယ်သော codebase ပါရှိသည်။ လူအနည်းငယ်သည် သီးသန့် UI အစိတ်အပိုင်းကို အာရုံစိုက်ပြီး၊ ကုဒ်သုံးသပ်ချက်များကို ရိုးရှင်းစေကာ အဖွဲ့အစည်းတစ်ခုလုံးကို တိုးတက်ကောင်းမွန်စေမည်ဖြစ်သည်။
- ရိုးရှင်းသောအက်ပ်စကေးချဲ့ခြင်း- micro frontends ၏နောက်ထပ်အကျိုးကျေးဇူးမှာ အင်္ဂါရပ်တစ်ခုစီကို တစ်ဦးချင်းစကေးချနိုင်မှုဖြစ်သည်။ အင်္ဂါရပ်အသစ်တစ်ခုထပ်ထည့်လိုက်တိုင်း ပရိုဂရမ်တစ်ခုလုံးကို စကေးချိန်ရမည်ဖြစ်သည့် monoliths နှင့် ဆန့်ကျင်ဘက်အနေဖြင့်၊ ၎င်းသည် လုပ်ငန်းစဉ်တစ်ခုလုံးကို အချိန်နှင့် ငွေကြေးအရ ပိုမိုထိရောက်စေသည်။
micro Frontend ဘယ်လိုအလုပ်လုပ်သလဲ။
ကျွန်ုပ်တို့ ယခင်ကပြောခဲ့သည့်အတိုင်း၊ အဖွဲ့များအား micro frontend ဗိသုကာတွင် ဒေါင်လိုက်ဖွဲ့စည်းထားပြီး ဆိုလိုသည်မှာ ၎င်းတို့ကို ဒိုမိန်းအသိပညာ သို့မဟုတ် ရည်ရွယ်ချက်ဖြင့် ပိုင်းခြားထားပြီး သီးခြားထုတ်ကုန်တစ်ခုအတွက် အစမှအဆုံးအထိ တာဝန်ရှိပါသည်။
၎င်းတွင် backend microservices တစ်ခု သို့မဟုတ် နှစ်ခုအပြင် သေးငယ်သော frontend တစ်ခုပါရှိသည်။ ပိုမိုအသေးစိတ်တွင်၊ ဤရုပ်မြင်သံကြားဒြပ်စင်၏လက္ခဏာများ၊ အခြား UI အစိတ်အပိုင်းများနှင့် အပြန်အလှန်တုံ့ပြန်မှုများ၊ ပင်မစာမျက်နှာတွင် ပေါင်းစပ်ပါဝင်မှုကို ဆန်းစစ်ကြည့်ကြပါစို့။
Micro Frontend လည်း ဖြစ်နိုင်ပါတယ်။
- စာမျက်နှာတစ်ခုလုံး (ဥပမာ၊ ထုတ်ကုန်အသေးစိတ်စာမျက်နှာ) သို့မဟုတ်
- ခေါင်းစီးများ၊ အောက်ခြေမှတ်စုများနှင့် ရှာဖွေရေးဘားများကဲ့သို့သော အခြားအဖွဲ့များက အသုံးပြုနိုင်သည့် စာမျက်နှာများ၏ အပိုင်းများ။
ဝဘ်ဆိုဒ်ကြီးတစ်ခုကို စာမျက်နှာအမျိုးအစားများစွာ ခွဲခြားနိုင်ပြီး အမျိုးအစားတစ်ခုစီကို လုပ်ကိုင်ရန် သီးခြားဝန်ထမ်းများအား ပေးနိုင်ပါသည်။
သို့သော်၊ ခေါင်းစီးများ၊ အောက်ခြေမှတ်စုများ၊ အကြံပြုချက်ဘလောက်များ စသည်တို့ကဲ့သို့သော စာမျက်နှာအများအပြားတွင် အစိတ်အပိုင်းများစွာကို မကြာခဏတွေ့ရလေ့ရှိသည်။ ဥပမာအားဖြင့် အကြံပြုချက်ဘလောက်ကို ပင်မစာမျက်နှာ၊ ထုတ်ကုန်အသေးစိတ်စာမျက်နှာ သို့မဟုတ် ငွေပေးချေမှုစာမျက်နှာတွင်ပင် ထည့်သွင်းနိုင်သည်။
အနှစ်သာရအားဖြင့်၊ အသင်းများသည် ၎င်းတို့၏ စာမျက်နှာများတွင် အခြားအဖွဲ့များ အသုံးပြုနိုင်သည့် အပိုင်းများကို ဖန်တီးနိုင်သည်။
သို့သော် ပြန်လည်အသုံးပြုနိုင်သော အစိတ်အပိုင်းများနှင့် ဆန့်ကျင်သည့် မတူခြားနားသော ပရောဂျက်များအဖြစ် မိုက်ခရိုမျက်နှာစာများကို သီးခြားစီချထားနိုင်ပါသည်။
ဤအရာအားလုံးသည် အံ့သြဖွယ်ကောင်းသော်လည်း တစ်စုတစ်စည်းတည်းရှိသော အင်တာဖေ့စ်တစ်ခုဖန်တီးရန်၊ စာမျက်နှာများနှင့် အပိုင်းအစများကို တစ်နည်းနည်းဖြင့် ပေါင်းစပ်ရမည်ဖြစ်သည်။
၎င်းသည် လမ်းညွန်ခြင်း၊ ဖွဲ့စည်းမှုနှင့် ဆက်သွယ်မှုအပါအဝင် မဟာဗျူဟာအမျိုးမျိုးမှတစ်ဆင့် ပြီးမြောက်အောင်မြင်နိုင်သည့် ရှေ့တန်းပေါင်းစပ်မှု လိုအပ်သည် (အထက်ဖော်ပြပါဂရပ်ဖစ်ကိုကြည့်ပါ)။
routing
အဖွဲ့တစ်ခုမှ ထိန်းချုပ်ထားသော စာမျက်နှာမှ ဝန်ဆောင်မှုသည် အခြားအဖွဲ့ပိုင်ဆိုင်သည့် စာမျက်နှာသို့ ဝင်ရောက်ရန် လိုအပ်သောအခါ၊ လမ်းကြောင်းပေးခြင်းသည် စာမျက်နှာအဆင့် ပေါင်းစည်းမှုအတွက် အသုံးဝင်ပါသည်။
micro frontend တိုင်းကို စာမျက်နှာတစ်ခုတည်း အပလီကေးရှင်းတစ်ခုအဖြစ် ကိုင်တွယ်သည်။ လမ်းကြောင်းပေးရန်အတွက် ရိုးရှင်းသော HTML လင့်ခ်များကို အသုံးပြုနိုင်သည်။
အသုံးပြုသူတစ်ဦးသည် ဆာဗာတစ်ခုမှ ပစ်မှတ်အမှတ်အသားကို ဒေါင်းလုဒ်လုပ်ရန်နှင့် ဟိုက်ပါလင့်ခ်များကို နှိပ်ခြင်းဖြင့် လက်ရှိစာမျက်နှာအသစ်နှင့် အစားထိုးရန် ဘရောက်ဆာအား ခိုင်းစေနိုင်သည်။
အပလီကေးရှင်းခွံသည် UI ကို အားကောင်းစေသည့် HTML၊ CSS နှင့် JavaScript တို့၏ အနိမ့်ဆုံးအနိမ့်ဆုံးဖြစ်သည်။ ဆာဗာမှ တောင်းဆိုထားသော အကြောင်းအရာဒေတာကို စောင့်ဆိုင်းနေသေးသော်လည်း၊ အသုံးပြုသူသည် ချက်ချင်းပြသထားသည့် တည်ငြိမ်သောစာမျက်နှာကို လက်ခံရရှိမည်ဖြစ်သည်။ ဗဟိုအက်ပ်ခွံသည် အဖွဲ့အမျိုးမျိုးမှဖန်တီးထားသော စာမျက်နှာတစ်ခုတည်းအက်ပ်များအတွက် ပင်မအပလီကေးရှင်းတစ်ခုအဖြစ် လုပ်ဆောင်သည်။
အသုံးပြုနေသည့် စာကြည့်တိုက် သို့မဟုတ် မူဘောင်များ ရှိပါစေ၊ meta-framework များသည် အမျိုးမျိုးသော စာမျက်နှာများကို တစ်ခုတည်းအဖြစ် ပေါင်းစပ်နိုင်စေပါသည်။
ဖွဲ့စည်းမှု
Composition သည် စာမျက်နှာတစ်ခုပေါ်ရှိ သင့်လျော်သောနေရာများအတွင်း ၎င်းတို့နှင့် အံဝင်ခွင်ကျဖြစ်စေရန်အတွက် အပိုင်းများကို စီစဥ်ပေးသည့်လုပ်ငန်းစဉ်ဖြစ်သည်။ ကိစ္စအများစုတွင်၊ စာမျက်နှာကို ဖြန့်ကျက်သောအဖွဲ့သည် အပိုင်းအစ၏ အကြောင်းအရာကို ချက်ချင်းမရယူပါ။
ယင်းအစား၊ ၎င်းသည် အပိုင်းအစကို အမှတ်အသားရှိသင့်သည့် နေရာတစ်ခု သို့မဟုတ် အမှတ်အသားတစ်ခု နေရာပေးသည်။
မတူညီသော ရေးဖွဲ့မှု လုပ်ငန်းစဉ်ကို အသုံးပြု၍ နောက်ဆုံး စည်းဝေးပွဲ ပြီးမြောက်ပါသည်။ ဖွဲ့စည်းမှုအား အခြေခံအမျိုးအစားနှစ်မျိုး- client-side နှင့် server-side ဟူ၍ခွဲခြားနိုင်သည်။
Client-side ဖွဲ့စည်းမှု: ဝဘ်ဘရောက်ဆာကို HTML markup ဖန်တီးရန်နှင့် တည်းဖြတ်ရန် အသုံးပြုသည်။ micro frontend တစ်ခုစီတွင် ၎င်း၏ markup ကို အခြားစာမျက်နှာမှ သီးခြားစီ ပြောင်းလဲနိုင်ပြီး ပြသနိုင်စွမ်းရှိသည်။
ဥပမာအားဖြင့်၊ Web Components၊ သင်သည် ဤတည်ဆောက်မှုအမျိုးအစားကို လုပ်ဆောင်ရန် ခွင့်ပြုသည်။
အစီအစဉ်သည် အပိုင်းအစတစ်ခုစီကို a.js ဖိုင်အဖြစ် သီးခြားထည့်သွင်းနိုင်သည့် ဝဘ်အစိတ်အပိုင်းတစ်ခုအဖြစ် ပြောင်းလဲရန်ဖြစ်ပြီး ၎င်းနောက်တွင် အက်ပ်များသည် ၎င်းတို့အတွက် သတ်မှတ်ထားသော နေရာလပ်များတွင် ၎င်းတို့ကို တင်ပြီး တင်ဆက်နိုင်မည်ဖြစ်သည်။
ဝဘ်အစိတ်အပိုင်းများသည် အခြားသော frontend frameworks များကို အသုံးပြုနိုင်သည့် HTML နှင့် DOM API ပေါ်တွင် မူတည်ပြီး props နှင့် event များမှတစ်ဆင့် ဒေတာပေးပို့ခြင်းနှင့် လက်ခံခြင်းဆိုင်ရာ စံနည်းလမ်းတစ်ခုဖြစ်သည်။
Server-side ဖွဲ့စည်းမှု: ဤဒီဇိုင်းဖြင့်၊ UI အပိုင်းများကို ဆာဗာပေါ်တွင် ပေါင်းစပ်ထားသောကြောင့် အပြည့်အ၀ဖွဲ့စည်းထားသော စာမျက်နှာကို ကလိုင်းယင့်ဘက်သို့ ပို့လိုက်ခြင်းဖြင့် loading ကို မြန်ဆန်စေသည်။
စည်းဝေးပွဲကို ဝဘ်ဘရောက်ဆာနှင့် ဝဘ်ဆာဗာများကြားတွင် သီးခြားဝန်ဆောင်မှုတစ်ခုဖြင့် လုပ်ဆောင်လေ့ရှိသည်။ CDN သည် ဝန်ဆောင်မှု (အကြောင်းအရာပေးပို့ခြင်းကွန်ရက်) ၏ ဥပမာတစ်ခုဖြစ်သည်။
သင့်လိုအပ်ချက်ပေါ်မူတည်၍ တစ်ခု သို့မဟုတ် နှစ်ခုကို ပေါင်းစပ်နိုင်သည်။
Micro Frontend ဆက်သွယ်မှုပုံစံများ
အစိတ်အပိုင်းအမျိုးမျိုးကြားတွင် အပြန်အလှန်သက်ရောက်မှုအနည်းငယ်မျှသာရှိသောအခါ မိုက်ခရို-မျက်နှာဖုံးဗိသုကာသည် အကောင်းဆုံးအလုပ်လုပ်သည်။ Micro Frontends များသည် ရံဖန်ရံခါ တစ်ဦးနှင့်တစ်ဦး စကားပြောရန်နှင့် အချက်အလက်များ မျှဝေရန် လိုအပ်သည်။ ဒါတွေက အဲဒါကို ဦးတည်သွားစေနိုင်တဲ့ အလားအလာရှိတဲ့ ပုံစံတချို့ပါ။
- ဝဘ်အလုပ်သမားများ− အွန်လိုင်းဝန်ထမ်းသည် ဝဘ်အကြောင်းအရာကို အခြား script များမပါဘဲ နောက်ခံတွင် JavaScript လည်ပတ်စေပြီး စာမျက်နှာ၏ အမြန်နှုန်းကို မထိခိုက်စေဘဲ လုပ်ဆောင်နိုင်သည့် ယန္တရားတစ်ခုဖြစ်သည်။ မိုက်ခရိုအက်ပ်တစ်ခုစီအတွက် သီးခြားလုပ်သား API ကို ပံ့ပိုးပေးပါမည်။ ဤအကျိုးကျေးဇူးမှာ UI thread ကို နှောင့်နှေးခြင်း သို့မဟုတ် ရပ်တန့်ခြင်းမရှိဘဲ ဆက်လက်လုပ်ဆောင်နိုင်စေရန်အတွက် အချိန်ကုန်အလုပ်အား မတူညီသော thread တစ်ခုတွင် လုပ်ဆောင်နိုင်ခြင်းဖြစ်သည်။
- ပွဲထုတ်သူ: ဤကိစ္စတွင်၊ များစွာသော အစိတ်အပိုင်းများသည် ၎င်းတို့စာရင်းသွင်းထားသည့် အစိတ်အပိုင်းများရှိ ပြည်နယ်အပြောင်းအလဲများကို နားထောင်ပြီး လုပ်ဆောင်ခြင်းဖြင့် အချင်းချင်း ဆက်သွယ်ကြသည်။ ထိုဖြစ်ရပ်အတွက် စာရင်းသွင်းထားသော အခြား micro frontends များသည် micro frontend မှ အဆိုပါ event ကို ပစ်ခတ်သည့်အခါ တုံ့ပြန်ပါသည်။ micro-frontend တစ်ခုစီတွင် မိတ်ဆက်ထားသော event emitter သည် ၎င်းကို ဖြစ်နိုင်ချေရှိသည်။
- ခေါ်ဆိုမှုများနှင့် ကျားကန်မှုများ: ဤကဏ္ဍတွင်၊ သင်သည် ပင်မအစိတ်အပိုင်းနှင့် ကလေးအစိတ်အပိုင်းများကို သတ်မှတ်သည်။ ဆက်သွယ်ရေးကို သစ်ပင်ပုံသဏ္ဍာန်အဖြစ် ဖွဲ့စည်းထားသည်။ မိဘအစိတ်အပိုင်းများသည် အချက်အလက်များကို အစိတ်အပိုင်းသစ်ပင်အောက်ရှိ ကလေးအစိတ်အပိုင်းများသို့ ပို့ဆောင်ရန် props များကို အသုံးပြုသည်။ တစ်ဖန်၊ ကလေးသည် ဖုန်းခေါ်ဆိုမှုများကို တုံ့ပြန်ခြင်းဖြင့် ၎င်းတို့၏ အခြေအနေတွင် တစ်စုံတစ်ရာ ဖြစ်ပေါ်သည့်အခါတွင် ကလေးသည် မိဘအား ထိရောက်စွာ သတိပေးနိုင်သည်။ React သည် ဤမုဒ်ကို အသုံးပြုသည်။
Micro frontend ၏အားသာချက်များ
လျင်မြန်စွာ ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရအဖွဲ့များတွင် ဖွံ့ဖြိုးတိုးတက်မှု
သီးခြားအဖွဲ့တစ်ဖွဲ့သည် micro frontend နည်းလမ်းကို အသုံးပြုသည့်အခါ ဝဘ်အက်ပ် သို့မဟုတ် ဝဘ်ဆိုက်တစ်ခုစီ၏ အစိတ်အပိုင်းတစ်ခုစီကို ဖန်တီးနိုင်သည်။
အဖွဲ့တစ်ခုစီသည် လုံး၀ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရရှိပြီး၊ ဆိုလိုသည်မှာ ၎င်းသည် သန္ဓေတည်ချိန်မှ ထုတ်လွှတ်ခြင်းအထိ နှင့် ထုတ်လုပ်ပြီးနောက်ပိုင်း အစိတ်အပိုင်းများ ဖွံ့ဖြိုးတိုးတက်ရေးစက်ဝန်းတစ်ခုလုံးတွင် တာဝန်ရှိပါသည်။
ထို့အပြင်၊ အဖွဲ့အသီးသီးသည် တူညီသောပရောဂျက်ကို တစ်ပြိုင်နက်လုပ်ဆောင်နေချိန်တွင် ချောမွေ့စွာပူးပေါင်းဆောင်ရွက်နိုင်သည်ဟု ဆိုလိုသည်။
ထို့ကြောင့်၊ ထုတ်လွှတ်သည့်စက်ဝန်းများသည် ရှေ့ဆုံး monoliths များထက် သိသိသာသာ ပိုမြန်သည်။
တစ်ဦးချင်း Micro Frontends ၏ ပိုသေးငယ်သော Codebases များသည် Cleaner Code သို့ ဦးတည်သည်။
Monolithic အရှေ့ဘက်စွန်းများတွင် ပိုပို၍ ဖရိုဖရဲဖြစ်လာပြီး အချိန်ကြာလာသည်နှင့်အမျှ စီမံခန့်ခွဲရန် စိန်ခေါ်မှုဖြစ်လာသည့် ကြီးမားပြီး ထိန်းမရသော ကုဒ်ဘေများရှိသည်။
Micro Frontends သည် ဤပြဿနာကို ဖြေရှင်းပေးသည်။ သေးငယ်သည်၊ ပိုရိုးရှင်းပြီး ပိုကျစ်လစ်သောကြောင့် micro frontend ၏ အရင်းအမြစ်ကုဒ်တစ်ခုစီသည် ပိုမိုစီမံခန့်ခွဲနိုင်သည်။
အကျိုးဆက်အနေဖြင့် ဝဘ်ဖြေရှင်းချက်သည် သန့်ရှင်းသောကုဒ်မှ အကျိုးကျေးဇူးများ ရရှိစေသည်။
Loose Coupling ကြောင့် အက်ပ်တည်ငြိမ်မှုကို မြှင့်တင်ထားသည်။
ဝဘ်ဖြေရှင်းချက်တစ်ခုအား လုံးဝလွတ်လပ်သောအပိုင်းများအဖြစ် ပိုင်းခြားရန် ရှားပါသည်။ ထို့ကြောင့် micro frontend များသည် အချင်းချင်း စကားပြောကြသည်။
သို့သော်၊ အစိတ်အပိုင်းများကြားရှိ ချိတ်ဆက်မှုတစ်ခုစီသည် လျော့ရဲသောချိတ်ဆက်မှုရှိနေသော်လည်း သိသာထင်ရှားပါသည်။
အစိတ်အပိုင်းတစ်ခု၏ ချို့ယွင်းမှုသည် ဝဘ်ဖြေရှင်းချက်၏ ပိုမိုကောင်းမွန်သော တည်ငြိမ်မှုကို ပံ့ပိုးပေးသည့် အခြားသော အစိတ်အပိုင်းအားလုံး၏ လည်ပတ်မှုအပေါ် အနည်းငယ်မျှ သက်ရောက်မှုမရှိပါ။
တစ်ဦးချင်းအင်္ဂါရပ်များကို စမ်းသပ်ခြင်းသည် ပိုမိုရိုးရှင်းပါသည်။
ဤအကျိုးကျေးဇူးသည် micro frontends ၏ဝိသေသလက္ခဏာများမှရလဒ်ဖြစ်သည်။ ဤဗိသုကာဒီဇိုင်းကိုအခြေခံ၍ ဝဘ်ဖြေရှင်းချက်၏ဖောက်သည်ဘက်တွင် မော်ဂျူလာဖြစ်ပြီး မော်ဂျူးတစ်ခုစီသည် ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရရှိသည်။
ရလဒ်အနေဖြင့်၊ အသုံးပြုသူအင်တာဖေ့စ်၏သေးငယ်သောအစိတ်အပိုင်းကို သူ့ဘာသာသူအကဲဖြတ်ခြင်းသည် ကြီးမားသော monolith ကိုစမ်းသပ်ခြင်းထက် အဖွဲ့တစ်ဖွဲ့အတွက်ပိုမိုလွယ်ကူသည်။
အစုအဝေးအရွယ်အစားကို လျှော့ချခြင်းဖြင့် စာမျက်နှာ Load ကို ပိုမိုမြန်ဆန်စေသည်။
အင်္ဂါရပ်ကြွယ်ဝသော monolithic ဝဘ်စနစ်များတွင် နှောင့်နှေးကြန့်ကြာရခြင်း၏ အဓိကအကြောင်းရင်းတစ်ခုမှာ JavaScript အစုအဝေးတစ်ခု၏ အရွယ်အစားဖြစ်သည်။ အခြားတစ်ဖက်တွင်၊ micro frontend ချဉ်းကပ်မှုသည် စာမျက်နှာဖွင့်ချိန်ကို လျှော့ချရန် ပိုမိုလွယ်ကူစေသည်။
ဝဘ်စာမျက်နှာတစ်ခုတွင် အစုအဝေးငယ်များစွာဖြင့် ဖွဲ့စည်းထားသောကြောင့် browser တစ်ခုသည် မလိုအပ်သောကုဒ်ကို ထပ်ခါတလဲလဲ ဒေါင်းလုဒ်လုပ်ရန် မလိုအပ်ပါ။ ရလဒ်အနေဖြင့် စာမျက်နှာစွမ်းဆောင်ရည်နှင့် တင်ချိန်များ တိုးလာသည်။
နည်းပညာလွတ်လပ်ရေး
အကွိမျမြားစှာ ရှေ့ဆုံးဘောင်များ micro-frontend ဗိသုကာဖြင့် အွန်လိုင်းဖြေရှင်းချက်တစ်ခုဖန်တီးရန် developer များက အသုံးပြုနိုင်သည်။
အစိတ်အပိုင်းတစ်ခုစီသည် ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရရှိသောကြောင့် အသင်း၏လုပ်ငန်းတာဝန်များနှင့် အကိုက်ညီဆုံးဖြစ်သော မည်သည့်နည်းပညာကိုမဆို အသုံးပြု၍ တည်ဆောက်နိုင်ပါသည်။
သဘာဝအားဖြင့်၊ ပရိုဂရမ်မာများသည် ၎င်းတို့တာဝန်ယူနေသော ဆော့ဖ်ဝဲလ်ပရောဂျက်အတွက် မူဘောင်များကို ရွေးချယ်ရာတွင် သတိထားသင့်ပြီး အခြားအဖွဲ့များနှင့် တိုင်ပင်ဆွေးနွေးမှုများကို ပြင်းပြင်းထန်ထန် အကြံပြုထားဆဲဖြစ်သည်။
သို့သော်၊ သင်သည် အက်ပ်၏သက်တမ်းတစ်လျှောက်တွင် အမွေအနှစ်ဘောင်တစ်ခုကို မဖြစ်မနေအသုံးပြုရန် အခွင့်အလမ်း လုံးဝမရှိပါ။
Micro Frontend ၏အားနည်းချက်များ
တစ်ခုလုံးအတွက် ရှုပ်ထွေးသော ဝဘ်ဖြေရှင်းချက် စမ်းသပ်ခြင်း။
ဝဘ်ဖြေရှင်းချက်၏ အမျိုးမျိုးသော module များကို စမ်းသပ်ခြင်းသည် micro-frontend ဗိသုကာကို အသုံးပြုသောအခါတွင် လွယ်ကူသည်။ သို့သော် ၎င်းသည် ဝဘ်အက်ပလီကေးရှင်းတစ်ခုလုံးကို အကဲဖြတ်ခြင်းနှင့် ကွဲပြားသည်။
ဆက်မလုပ်မီ အစိတ်အပိုင်းအားလုံးသည် ရည်ရွယ်ထားသည့်အတိုင်း လုပ်ဆောင်ကြောင်း အတည်ပြုပါ။ Micro Frontends များသည် သီးခြားလုပ်ဆောင်နေပြီး သီးခြားပေးပို့ခြင်းလုပ်ငန်းစဉ်များ ရှိသောကြောင့် ၎င်းသည် ခက်ခဲနိုင်သည်။
စျေးကြီးသော ကနဦးရင်းနှီးမြှုပ်နှံမှုများ
Micro Frontend တိုးတက်မှုများသည် ပုံမှန်အားဖြင့် များပြားသော ငွေကြေးအသုံးစရိတ်များကို တောင်းဆိုလေ့ရှိသည်။ ရှေ့တန်းအသင်းများစွာကို စုစည်းပြီး ထားရှိရန် စျေးကြီးသည်။
ထို့အပြင်၊ အလုပ်အကိုင်ကို စုစည်းရန်၊ အရာအားလုံးကို ညှိနှိုင်းဆောင်ရွက်ပေးရန်၊ ကောင်းမွန်သောအဖွဲ့၏ ဆက်သွယ်မှုကို အာမခံရန် စီမံခန့်ခွဲရေးဝန်ထမ်းများ လိုအပ်မည်ဖြစ်သည်။
ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ဖြန့်ကျက်မှုဆိုင်ရာ ရှုပ်ထွေးမှု
micro-frontend ဒီဇိုင်းကြောင့် ဖွံ့ဖြိုးတိုးတက်မှုနှင့် အသုံးချမှုလုပ်ငန်းစဉ်များသည် ပိုမိုရှုပ်ထွေးလာနိုင်သည်။
ဥပမာအားဖြင့် တူညီသောပရောဂျက်တွင် လုပ်ဆောင်နေသော အမှီအခိုကင်းသော ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များက အစိတ်အပိုင်းများစွာဖြင့် ရှုပ်ပွနေနိုင်ပြီး၊ ဥပမာအားဖြင့်၊ အသုံးချမှုအဆင့်တွင် ပြဿနာများဖြစ်စေနိုင်သည်။
မော်ဂျူးများအားလုံး၏ မှန်ကန်သောစုဝေးမှုနှင့် အလုံးစုံအစီအစဉ်တွင် ၎င်းတို့၏ ချောမွေ့စွာပေါင်းစည်းမှုသည် အမြဲတမ်းမရိုးရှင်းပါ။ ဤလုပ်ငန်းသည် အများအားဖြင့် မှီခိုမှုအားလုံးကို စေ့စေ့စပ်စပ် နားလည်ရန် လိုအပ်သည်။
အသုံးပြုသူအတွေ့အကြုံရှိ ညီညွတ်မှုကို ထိန်းသိမ်းခြင်း ပြဿနာများ
အဖွဲ့များသည် ဆော့ဖ်ဝဲလ်၏ အစိတ်အပိုင်းများစွာတွင် သီးခြားစီလုပ်ဆောင်သည့်အခါ တသမတ်တည်း အသုံးပြုသူ အင်တာဖေ့စ်ကို ထိန်းသိမ်းခြင်းသည် စိန်ခေါ်မှုဖြစ်သည်။
ဝဘ်ဖြေရှင်းချက်အား ပရောဂျက်၏ ဆော့ဖ်ဝဲရေးသားသူအားလုံးမှ မျှဝေသင့်သည်။ မဟုတ်ရင် လမ်းတလျှောက်မှာ ကွဲလွဲမှုတွေ အများကြီး ရှိနိုင်ပါတယ်။
ကောက်ချက်
ခေတ်ပြိုင်ဗိသုကာဒီဇိုင်းဖြစ်သော Micro Frontends သည် ကြီးမားသော microservice-based web development ပရောဂျက်များ၏ စွမ်းဆောင်ရည်ကို မြှင့်တင်ပေးနိုင်ပါသည်။
၎င်းသည် ပရိုဂရမ်မာများအား ပြီးပြည့်စုံသောအဖြေကို ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရအဖွဲ့များစွာမှ ဖန်တီးနိုင်သည့် သီးခြားအစိတ်အပိုင်းများအဖြစ် ပိုင်းခြားနိုင်စေပါသည်။ ပိုမိုမြန်ဆန်သော လုပ်ဆောင်ချက် ထုတ်ပေးခြင်း၊ တစ်ဦးချင်းစီ မော်ဂျူးများကို ပိုမိုလွယ်ကူစွာ စမ်းသပ်ခြင်းနှင့် ချောမွေ့မှုမရှိသော အဆင့်မြှင့်တင်ခြင်းများ အပါအဝင် အကျိုးကျေးဇူးများစွာ ရရှိပါသည်။
ဒါပေမယ့် micro Frontends မှာလည်း အခက်အခဲအချို့ရှိပါတယ်။
ဥပမာအားဖြင့် အပလီကေးရှင်းတစ်ခု၏ ကျယ်ကျယ်ပြန့်ပြန့်စမ်းသပ်မှုသည် စိန်ခေါ်မှုဖြစ်နိုင်သည်။
ထို့အပြင်၊ အင်ဂျင်နီယာများနှင့် စီမံခန့်ခွဲသူများအဖွဲ့ အများအပြား လိုအပ်သောကြောင့်၊ micro frontend ပရောဂျက်များသည် အလွန်စျေးကြီးပါသည်။
ထို့ကြောင့် ဆုံးဖြတ်ချက်တစ်ခုမချမီ၊ သင့်လုပ်ငန်းကိစ္စရပ်၏ အစိတ်အပိုင်းအားလုံးကို ထည့်သွင်းစဉ်းစားရပါမည်။
ဗလာဒီမီယာ Čamaj
ရှေ့တန်းရှိ အစိတ်အပိုင်းတစ်ခုချင်းကြား ဆက်သွယ်မှုမှာ မည်သည့်နိယာမကို ကျွန်ုပ်နားမလည်ခဲ့ပါ။ မတူညီသောဘောင်များတွင် ဖန်တီးထားသော အစိတ်အပိုင်းများကို သင်မည်ကဲ့သို့ချိတ်ဆက်လိုသည်ကို ကျွန်ုပ်နားမလည်ပါ။ အဲဒီအကြောင်း ဆောင်းပါးထဲမှာ ဘာမှ မရှိပါဘူး။ အဖြစ်အပျက်များနှင့် နားထောင်သူများ၏ စနစ်သည် ကျွန်ုပ်အတွက် ကမ္ဘာမြေငရဲနှင့်တူသည်။ အဲဒါကို ကျွန်တော်တို့ ဘယ်လို စိတ်ကူးယဉ်သင့်လဲ။