Բառը[Թաքցնել][Ցուցադրում]
- Այսպիսով, ինչ է մոդուլային ֆեդերացիան:
- Ինչու՞ մոդուլի ֆեդերացիա:
- Մոդուլի ֆեդերացիայի հիմնական բաղադրիչները
Ֆեդերացիայի մոդուլի հիմնական առանձնահատկությունները+-
- Գերազանց վեբ կատարում
- Արդյունավետ զարգացում
- Ինքնաբուժման կարողություն և ավելորդություն
- Ընդհանուր կախվածությունների արդյունավետ կառավարում
- Սպառողներին նորից տեղակայելու փոխարեն, տեղադրեք անկախ կոդ:
- Աշխատելիս ներմուծեք կոդը այլ կառուցապատումներից:
- Ընդլայնված ծրագրավորողների փորձը` պահպանելով հաճախորդի փորձը
- Micro-frontend-ները գործում են միաձույլ ձևով:
- Եզրափակում
Micro frontends-ի հայեցակարգը կիրառում է microservices frontend-ի մշակման համար:
Գաղափարն այն է, որ հավելվածը կամ վեբ կայքը բաժանվի ավելի փոքր, ինքնուրույն մշակված մասերի, որոնք այնուհետև միանում են գործարկման ընթացքում՝ ի տարբերություն դրանք որպես միասնական, միասնական մոնոլիտ ստեղծելու:
Մեթոդը հնարավորություն է տալիս ստեղծել հավելվածի այլ բաղադրիչներ՝ օգտագործելով այլ տեխնոլոգիաներ և անկախ թիմերով:
Գաղափարն այն է, որ կրճատվեն տիպիկ մոնոլիտի հետ կապված պահպանման ծախսերը՝ այս կերպ զարգացումը սեգմենտավորելով:
Թույլ տալով նրանց կենտրոնանալ հավելվածի որոշակի տարածքի վրա՝ որպես համահունչ թիմ, այն նաև հնարավոր է դարձնում համագործակցության նոր ձևեր backend-ի և frontend-ի մշակողների միջև:
Օրինակ, դուք կարող եք ունենալ թիմ, որը բացառապես պատասխանատու է որոնման հնարավորության կամ հիմնական արտադրանքի մեկ այլ ասպեկտի համար, որը կարևոր է բիզնեսի համար:
Մոդուլի ֆեդերացիայի շնորհիվ դուք ունեք բավականաչափ ֆունկցիոնալություն՝ կարգավորելու աշխատանքային հոսքը միկրո ճակատ մոտեցման մանդատները.
Այս գրառումը խորը կանդրադառնա մոդուլի ֆեդերացիայի ճարտարապետությանը, ինչպես նաև դրա հիմնական առանձնահատկություններին և կիրառական օրինաչափություններին:
Այսպիսով, ինչ է մոդուլի ֆեդերացիա?
Javascript-ի մոդուլի ֆեդերացիայի դիզայնը օգտագործում է կրկնակի օգտագործվող մասեր բազմաթիվ ծրագրերում:
Դա բավականին տարրական ժարգոն է, բայց ես պարզապես այնպես եմ արել, որ կարծես թե հով է:
Քանի որ մենք բոլորս ծանոթ ենք React հավելվածում բաղադրիչների փոխանակմանը, Module Federation-ը գործնականում արդյունավետորեն իրականացնում է նույն նպատակը, բացառությամբ, որ այն դինամիկ կերպով բացահայտում է հավելվածի մոդուլները՝ այլ հավելվածների կողմից սպառման համար:
Module Federation-ը ձգտում է հաղթահարել բաշխված համակարգում մոդուլների փոխանակման խնդիրը՝ այդ հիմնական ընդհանուր տարրերը տրամադրելով որպես մակրո կամ միկրո ըստ ցանկության:
Դա արվում է՝ դրանք հեռացնելով ձեր հավելվածներից և կառուցման աշխատանքային հոսքից:
Ինչու՞ մոդուլի ֆեդերացիա:
Ահա մի քանի գործոններ, որոնց հետ մոդուլի ֆեդերացիան կարող է հեշտությամբ կարգավորել.
- Արտաքին և DLL-ները (Dynamic Link Libraries) այն ամենն էին, ինչ մենք երբեմն ունեինք հավելվածների միջև ֆունկցիոնալությունը կիսելու համար: Այս ամենն էլ չափազանց դժվար էր դարձնում կոդի մասշտաբային փոխանակումը:
- NPM-ը դանդաղ է.
- Երբ երկու առանձին ծրագրեր կիսում են կարևոր կոդը, դրանք պետք է լինեն դինամիկ և ճկուն:
Որպեսզի ինքնուրույն հավելվածներն ամբողջությամբ լինեն իրենց պահոցում, տեղակայվեն առանձին և գործեն որպես իրենց անկախ SPA, ստեղծվել է Module Federation:
Մոդուլի ֆեդերացիայի հիմնական բաղադրիչները
Մինչ ավելի խորը սուզվելը, կարևոր է համառոտ քննարկել մի քանի նոր գաղափարներ, որոնք բերում է մոդուլի ֆեդերացիան:
- Հոսթ. Երբ էջը բեռնվում է, սկզբնապես նախաստորագրված կառուցվածքը կամ մոդուլը կոչվում է հոսթ: Պրովայդերը կարելի է համարել որպես հյուրընկալող:
- Հեռակառավարում. Հեռակառավարիչը տարբեր կառուցվածք է, որն օգտագործում է հյուրընկալողի մի մասը: Նրանք նաև կոչվում են հաճախորդներ:
- Երկուղղորդված հոսթ. Webpack build, որը գործում է և որպես հեռակառավարիչ, որը օգտագործում են մյուս հոսթները, և որպես հոսթ, որը սպառում է հեռակառավարվող սարքերը:
- Վաճառողի դաշնություն. հնարավորություն է տալիս npm մոդուլի կախվածությունների դեկլարատիվ համօգտագործման համօգտագործումը հոսթի կամ հեռակառավարման համար, անկախ այն վայրից, որտեղից դրանք բեռնված են: Միկրո ճակատների հետ կապված հիմնական կատարողական խնդիրներից մեկը լուծվում է այս կերպ:
Դաշնային կիրառման ձևերը
Evergreen Design System
Դաշնային հավելվածների ամենահիմնական ձևերից մեկը «մշտադալար հեռակառավարումն» է, որը ընդհանուր հեռակառավարման վահանակ է, ինչպիսին է «Դիզայնի համակարգը» կամ «Բաղադրիչ գրադարանը», որը ինքնուրույն բաշխվում և թարմացվում է բոլոր օգտագործողների համար:
Առանց յուրաքանչյուր հավելվածի թիմի վերանայումների վրա ժամանակ ծախսելու, սա կարող է օգտակար լինել՝ ապահովելու համար, որ բոլոր առցանց կայքերը կառչեն ամենավերջին կորպորատիվ ինքնությանը:
Անվտանգ, շարունակական թարմացումները երաշխավորելու համար անհրաժեշտ սահմաններն ու ընթացակարգերը նախագծելու և գործադրելու համար սա կարող է օգտակար տեղ լինել բիզնեսի համար՝ սկսելու համար դաշնային հավելվածների ճարտարապետությունը դիտարկելիս:
Ստորև բերված են օգտագործման մի քանի դեպքեր, երբ ինքնուրույն տեղակայված ընդհանուր հեռակառավարման սարքերը կարող են հարմար լինել.
- Դիզայնի համակարգեր
- Կիրառական պատյաններ
- Բաղադրիչ գրադարաններ
- Սպառողների
- Համօգտագործվող գործիքների հավաքածուներ
- Այլընտրանքային բաշխման մոդելներ վիդջեթների համար, որոնք օգտագործվում են ներքին կամ արտաքին
Multi-SPA մոդուլների փոխանակում
Կրկին օգտագործեք արդեն արտահանված գործառույթները, ինչպիսիք են բաղադրիչները, տարբեր առանձին մեկ էջանոց հավելվածներում: Առավելությունները ներառում են.
- Սպառողները ստանում են ավտոմատացված թարմացումներ
- Դոմենի փորձաքննությունը մնում է այն թիմի վրա, որը պատասխանատու է դրա համար:
- Հեշտացնում է տեղակայման ընթացակարգը, քանի որ առանձին մոդուլների թողարկումներ անհրաժեշտ չեն:
Շելլային ֆեդերացիա
Ռումբերով առաջնորդվող ֆեդերացիան ներառում է.
- Ապրանքի նոր տարբերակ ստեղծելիս Ապրանքի թիմը չի սպասում, որ Checkout թիմը ավարտի իր աշխատանքը:
- Հեռակառավարման սարքերը փոխարկելիս էջի վերաբեռնում չկա:
- Անհրաժեշտության դեպքում Shell-ն առաջարկում է դանդաղ հեռաբեռնում և (վերին մակարդակի) երթուղում:
- Հեռակառավարման սարքերով երթուղավորումը հնարավոր է դառնում վաճառողների դաշնության միջոցով, որը հնարավորություն է տալիս հաճախակի օգտագործվող npm փաթեթների վերօգտագործումը:
- Shell-ն առաջարկում է շրջանակ և այլ սովորական կախվածություններ, որոնք նորից օգտագործվում են ծույլ բեռնված հեռակառավարման սարքերի կողմից:
Multi-shell ֆեդերացիա
Նման է վերը նկարագրված կճեպով առաջնորդվող ֆեդերացիային, սակայն օգտագործվում են տարբեր կճեպներ:
Այն պարունակում է.
- մի շարք պատյաններ
- Սպիտակ պիտակավորում
- Ոչ բոլոր հեռակառավարիչները պահանջվում են Shell B-ի կողմից կամ ունեն անկախ իրականացում:
Ֆեդերացիայի մոդուլի հիմնական առանձնահատկությունները
Գերազանց վեբ կատարում
Նորմալ NPM մոդուլի կազմի խնդիրն այն է, որ կախյալների թվի աճի հետ հայտի չափն ընդհանուր առմամբ մեծանում է:
Որպեսզի խուսափեք փաթեթների բեռնումից, երբ ձեր հավելվածը բեռնվում է և միայն անհրաժեշտության դեպքում, Module Federation-ն առաջարկում է ձեզ ծուլորեն բեռնել փաթեթները:
Սա կանխում է մոդուլները ներբեռնելու անհրաժեշտությունը նախքան դրանք իրականում պահանջելը, ինչը բարելավում է կայքի արագությունը:
Արդյունավետ զարգացում
Յուրաքանչյուր նախագիծ կարող է արտադրվել և մատուցվել առանձին և կարող է իրականացվել տարբեր թիմերի կողմից, քանի որ Module Federation-ը խրախուսում է ձեզ կազմակերպել ձեր հայտը առանձին նախագծերի, որպեսզի կարողանաք կառուցել և տեղակայել դրանք առանձին (և հետևաբար՝ զուգահեռ):
Ինքնաբուժման կարողություն և ավելորդություն
Համօգտագործվող կախվածությունները թույլ են տալիս Module Federation-ին հետևել ձեր ծրագրի բոլոր կախվածություններին մեկ տեղում:
Այս կերպ, նույնիսկ երբ հավելվածը չի հայտարարում կախվածության մասին կամ երբ առկա են ցանցային խնդիրներ, այն դեռ գիտի, թե ինչ է իրեն անհրաժեշտ և կարող է անհրաժեշտության դեպքում բեռնել այն:
Ընդհանուր կախվածությունների արդյունավետ կառավարում
Բացի այդ, Module Federation-ն առաջարկում է բարձրակարգ կախվածության կառավարում, արդյունավետորեն լուծելով վաճառողի և երրորդ կողմի պահանջները, որպեսզի ձեր հավելվածը երբեք չբեռնի գրադարանի մեկից ավելի տարբերակներ:
Սպառողներին նորից տեղակայելու փոխարեն, տեղադրեք անկախ կոդ:
Մշակողը մեծապես հետաքրքրված է մշտադալար ֆունկցիոնալությամբ: Երբ բացահայտված կախված ֆունկցիոնալությունը փոխվի, այլևս կարիք չի լինի նորից տեղադրել սպառողներին:
Պետք է խոստովանեմ, որ սա ինքնին շատ հզոր հատկանիշ է, որը մանրազնին քննության կարիք կունենա՝ կանխելու անսպասելի արդյունքները:
Աշխատելիս ներմուծեք կոդը այլ կառուցապատումներից:
NPM փաթեթի մոդելն ընդունելիս մենք կարող ենք դիտարկել հավելվածներ, որոնք օգտագործում են Module Federation-ը նման API-ներին, այլ ոչ թե կիսում են կոդը և մտածում «գրադարան»-ի մասին:
Նույն ձևով, որ նրանք կարող են նաև ֆունկցիոնալություն ստանալ այլ հավելվածներից, վեբ հավելվածներն այժմ կարող են ֆունկցիոնալությունը տրամադրել այլ հավելվածներին:
Ընդլայնված ծրագրավորողների փորձը` պահպանելով հաճախորդի փորձը
Ցանկացած JavaScript ծրագրավորող բավականին հարմար կլինի Module Federation-ի հետ, քանի որ այն Webpack հավելված է, որը հասանելի է Webpack տարբերակի 5-ից:
Սա իրականում բավականին ուժեղ և ինտրիգային է, եթե մտածենք դրա մասին:
Օգտագործելով երրորդ կողմի Webpack բեռնիչները, հաշվի առեք բոլոր այն բաղադրիչները, որոնք Վեբկապ փաթեթներ, ներառյալ սցենարներ, ակտիվներ, ոճեր, նկարներ, նշումներ և այլն:
Օգտագործելով Module Federation-ը, այս ամենը կարելի է համօգտագործել և դաշնակցել:
Micro-frontend-ները գործում են միաձույլ ձևով:
Բավականին հեշտ է ձեր հավելվածին համատեղ ֆունկցիոնալություն ավելացնելը. պարզապես ներմուծեք փաթեթը որպես սովորական կամ օգտագործեք համաժամանակյա բեռնում:
Որպես այլընտրանք, ասինխրոն բեռնումը կարող է օգտագործվել միայն անհրաժեշտության դեպքում կախվածությունը բեռնելու համար՝ օգտագործելով ծույլ բեռնումը:
Եզրափակում
Այս գրառման մեջ մենք քննարկել ենք Module Federation-ը որպես ֆանտաստիկ ընտրություն՝ ձեր միկրո-frontend հավելվածը մշակելու համար:
Թույլ տալով, որ հավելվածները փոխանակվեն և օգտագործեն ֆունկցիոնալությունը գործարկման ժամանակ, խթանում է մասշտաբայնությունը՝ հնարավորություն տալով տարբեր թիմերին աշխատել անկախ հավելվածների վրա:
Երբ ընդհանուր ֆունկցիոնալությունը փոխվում է, դուք կարիք չեք ունենա նախագծել և տեղակայել ձեր սպառողներին, քանի որ այն աջակցում է մշտադալար ֆունկցիոնալությանը:
Ձեր ծրագիրը կգործի մոնոլիտի նման այն ստեղծվելուց հետո, ինչը ֆանտաստիկ է:
Համօգտագործվող կախվածություններն օգտագործվում են հավելվածների չափը նվազեցնելու համար: Քանի որ շատ մշակողներ արդեն ծանոթ են Webpack միջավայրին, ծրագրավորողների փորձը գերազանց է:
Թողնել գրառում