Micro-frontends Single-SPA-ով, օգտագործելով ծանրոցների կոնֆիգուրացիա

Նախքան թեմային անցնելը…

Frontend-ը պետք է մշակվի արտադրանքի սեփականատիրոջ կողմից վստահելի հավաստիացմամբ այն հատկանիշների համար, որոնք այն տալիս է: Եթե ​​առանձնահատկությունները չեն համապատասխանում արտադրանքի սեփականատիրոջ գաղափարախոսությանը կամ եթե անհրաժեշտ է ավելացնել ավելի շատ գործառույթներ, ապա մշակման թիմը պետք է կարողանա կատարել անհրաժեշտ փոփոխությունները՝ նվազագույն ազդեցություն ունենալով հավելվածի վրա: Եվ նաև, թիմի յուրաքանչյուր անդամ պետք է խորը գիտելիքներ ունենա միաձույլ կոդերի բազայի վերաբերյալ, որի վրա նրանք աշխատում են իրենց կատարած ցանկացած փոփոխություն կատարելու համար՝ առանց հավելվածը խախտելու: Առջևի զարգացման մասշտաբը, որտեղ հնարավորինս շատ թիմեր կարող են միաժամանակ աշխատել մեծ և բարդ նախագծի վրա, անհնարինների ցանկում է և ավելի դժվար է հասնել: Ապրանքի սեփականատիրոջ կողմից սահմանված ժամկետում անհրաժեշտ փոփոխությունների համար ճնշումը և դժվար հասկանալի միաձույլ ծածկագրի հիմքի վերաբերյալ թիմի անդամների շփոթությունը հանգեցնում է պարզաբանման համար հաղորդակցության ժամանակի վատնման հուսահատության և հիասթափության:

Այժմ անցնենք թեմային…

Այնուհետև մտածեք, թե ինչպես է մոնոլիտ հետնամասը բաժանվում կառավարելի մասերի, մասնավորապես՝ միկրոծառայությունների: Նույն ձևով ճակատային մասի դեպքում, դա հնարավոր է ձեռք բերել միկրո-առանցքային ճարտարապետության միջոցով, որը մեծացնում է ճակատային կոդի վրա աշխատող թիմերի արդյունավետությունն ու արդյունավետությունը: Ինչպես անունն է հուշում, frontend-ը կբաժանվի մասերի, որտեղ յուրաքանչյուր թիմ կարող է ինքնուրույն աշխատել՝ հնարավորությունները մատուցելու համար:

Հիմնական առավելությունները, որոնք կարելի է ձեռք բերել միկրո-ճակատներից, ավելի փոքր և հասկանալի կոդերի բազաներն են, անկախ աշխատող թիմերի հետ լայնածավալության բարձրացումը, հավելվածում թարմացումների և փոփոխությունների մատուցման հեշտությունն ու արդյունավետությունը:

Micro-frontend ճարտարապետությունը գալիս է մեկ էջի հավելվածներով, որտեղ որոշակի էջի առանձնահատկությունները կարելի է բաժանել միկրո frontend-ների, որպեսզի դրանք բաշխվեն ինքնավար թիմերի միջև աշխատելու համար: Յուրաքանչյուր հատկանիշի բաղադրիչ ինքնուրույն կփոխանցվի DOM և որևէ ազդեցություն չի ունենա այլ գործառույթների վրա: Հատկությունների միջև նման տարանջատման պատճառով յուրաքանչյուր թիմ, հնարավոր է, աշխատի իր հանձնարարված առաջադրանքի վրա՝ առանց որևէ հաղորդակցության կամ պարզաբանման այլ թիմերի կողմից՝ իրենց ընթացակարգին հետևելու համար:

Երբ օգտագործել…

Դուք չպետք է օգտագործեք միկրո-ճակատներ, քանի որ թվում է, թե դա գեղեցիկ հիանալի հատկություն է…! Հատկանիշների ընտրությունը պետք է կատարվի մասշտաբայնության և բարդության վրա: Եթե ​​առանձնահատկությունը թվում է, թե ավելի բաժանելի է ենթատիրույթների, ապա աշխատեք այդ հատուկ հատկանիշի վրա որպես առանձին միկրո-առանցք: Սա կարող է ձեզ հեշտությամբ կառավարել ձեր կոդերի բազան՝ առանց մեկ մոնոլիտ կոդային բազայի հետ գործ ունենալու ցավի:

Ներածություն համագործակցության աշխարհի օրինակին…

Ես հանդիպել եմ մի նախագծի, որտեղ մի հավելված, որը պատահաբար վեբ պորտալ է, որի միջոցով մենք կարող ենք մուտք գործել մեկից ավելի հավելվածներ:

Այն ավելի հստակեցնելու համար ես կթվարկեմ կոդերի հիմքերը, որոնց վրա աշխատել է իմ թիմը: (յուրաքանչյուրը ներկայացնում է միկրո-առանցք)

1. Վեբ պորտալ — գործում է որպես դարպաս կամ պորտալ՝ այլ հավելվածներ մուտք գործելու համար:
2. Dashboard- հավելվածներից մեկը, որը հասանելի է SPA-ի ենթատիրույթների միջոցով:
3. Վճարման հայտ — հավելվածներից մեկը, որը հասանելի է SPA-ի ենթատիրույթների միջոցով:

Հետևյալ github պահեստները օգտակար կլինեն որոշակի լույս սփռելու համար, երբ դուք շարժվում եք ծանրոցների կազմաձևմամբ:

Դրա համար նախ կլոնավորեք ռեպոները և արեք հետևյալը.

npm install և npm start

Ըստ իմ տեսակետի, ես առաջարկում եմ միկրո-ճակատներից օգուտներ ստանալու լավագույն միջոցը կլինի յուրաքանչյուր ուղղահայաց թիմ աշխատել համապատասխան միկրո-ճակատների ծայրից ծայր հոսքի վրա: Դա նշանակում է ոչ միայն ճակատային, այլ նաև հետին մասի միացում՝ միկրո ծառայությունների մատուցման համար: Արդյունքում, յուրաքանչյուր թիմ կունենա լիարժեք ճանաչում և հասանելիություն՝ համապատասխան ճակատային մասում, BFF (backend-for-frontend) կամ հետին մասում որևէ փոփոխություն կատարելու համար՝ առանց որևէ ազդեցության այլ թիմերի ընթացակարգերի վրա:

Հետևաբար, մենք ունեինք հետևյալ հավելվածների ճարտարապետությունը՝ յուրաքանչյուր թիմին տրամադրելու համար աշխատել իրենց կոդերի բազաների վրա՝ առանց ուրիշների վրա հենվելու:

Ինչպես է միայնակ SPA-ն հայտնվում պատկերում…

Single-SPA-ն շրջանակ է, որն ապահովում է micro-frontend-ի ճարտարապետության հնարավորությունները, որտեղ մի քանի javascript-ի միկրո-frontends հնարավոր է կապվել միմյանց հետ frontend հավելվածում: Single-SPA-ով մենք կարող ենք օգտագործել մի քանի շրջանակներ նույն էջում առանց էջի թարմացման (React, AngularJS, Angular և այլն):

Հետևյալը կլինի պաշտոնական փաստաթղթերը միայնակ սպա-ի համար:

Անցեք փաստաթղթերի միջով՝ ձեզ առաջնորդելու հաջորդ բաժինը:

Single-SPA իրականացում

Single-SPA-ի դեպքում միայն մեկ հավելված ունի index.html, որը DOM-ն էորտեղ մենք ներկայացնում ենք մեր բոլոր բաղադրիչները: Ահա, այս օրինակում վեբ պորտալը պարունակում է index.html ֆայլ և այն ներկայացնում է այլ հավելվածներ ենթատիրույթի ռեժիմով:

Դա անելու համար յուրաքանչյուր հավելված պետք է կազմաձևվի և գրանցվի մեկ սպա կոնֆիգուրացիայի ֆայլում, որպեսզի թույլ տա գործարկել, բեռնել, տեղադրել և ապամոնտաժել:

registerApplication(name, loadingFunction, activityFunction)

registerApplication api կանչելու համար դուք պետք է սահմանեք loadingFunctionbundle.js ֆայլը համապատասխան հավելվածի և activityFunction ներմուծելու համար: >որտեղ հավելվածը տեղադրվում է, երբ ուղղորդվում է դեպի տվյալ ուղին:

Այստեղ ես ավելին չեմ քննարկի իրականացման մասին, քանի որ այն արդեն տրամադրված է իրականացման մանրամասներով փաստաթղթերում և github պահեստում:

Այժմ եկեք անցնենք ամենակարևոր թեմայինինչպես և ինչու ծանրոցների կազմաձևում:

Ծանրոցների կազմաձևում

Այն, ինչին մենք ցանկանում էինք հասնել միայնակ սպա-ից, հնարավորությունների բաժանումն էր՝ ինքնուրույն աշխատելու համար: Բայց ինչ անել, եթե որոշ տվյալներ փոխանցվեն հիմնական հատկանիշից մյուս հատկանիշներին: Դա իրականում կհանգեցնի առանձնահատկությունների միջև ինչ-որ զուգավորման, բայց, այնուամենայնիվ, դա հնարավոր չէ խուսափել, եթե տվյալները փոխանցվեն:

Դա անելու համար լռելյայն հենակետերը կարող են փոխանցվել յուրաքանչյուր հավելվածի registerApplication api-ով: Սակայն այն բանից հետո, երբ հավելվածը բեռնաթափվի և տեղադրվի, փոխանցված հենակետերը չեն կարող փոխվել, նույնիսկ եթե անցնող հենակետերի տվյալները կարող են փոխվել հիմնական գործառույթում: Դա պայմանավորված է նրանով, որ registerApplication api-ի միջոցով հնարավոր չէ կյանքի ցիկլի մեթոդ տրամադրել յուրաքանչյուր հավելվածին, որպեսզի թարմացվի իր բովանդակության փոփոխություններով:

Տվյալ օրինակում մենք ունենք 2 հավելված (վճարման վահանակ և վճարում), որոնք գրանցված են որպես մեկ SPA հավելված վեբ պորտալում: Քանի որ մենք պատրաստվում ենք օգտատերերի մուտքագրում ունենալ վեբ պորտալում և փոխանցել այն այս 2 հավելվածներին, մենք պետք է ունենանք հենակետերը թարմացնելու միջոց, այլ ոչ թե ունենանք կանխադրված հենակետեր փոխանցելու միջոց, ինչպես registerApplication API-ում: Այդ ծանրոցների կոնֆիգուրացիան անհրաժեշտ է, որտեղ մենք կարող ենք տալ թարմացման կյանքի ցիկլի մեթոդ յուրաքանչյուր հավելվածին: Եվ մասնավորապես, վեբ պորտալում կարիք չկա տրամադրել առանձին մեկ սպա-կոնֆիգուրայի ֆայլ՝ գրանցված հավելվածները սկսելու համար:

Յուրաքանչյուր հավելված կարող է տեղադրվել DOM-ում որպես սովորական բաղադրիչ՝ վեբ պորտալում տրամադրված պահանջվող հենարաններով հետևյալ կերպ. (Հստակության համար ես այստեղ ավելացրեցի վեբ պորտալի հիմնական բաղադրիչը)

Այստեղ դուք կարող եք տեսնել, որ մենք կարող ենք տեղադրել մեր հավելվածը որպես ռեակտիվ բաղադրիչ՝ մեկ SPA ծանրոցի օգնությամբ: Արդյունքում մենք կարող ենք փոխանցել հենարանները ճիշտ այնպես, ինչպես սովորական արձագանքման բաղադրիչը:

Այստեղ օգտագործողի մուտքագրումը ստանալու բաղադրիչը տեղադրվում է վեբ պորտալի միջոցով, և վահանակի և վճարային հավելվածի յուրաքանչյուր կոճակ վերահղվում է համապատասխան հավելվածին: Քանի որ մենք օգտագործում ենք Parcel բաղադրիչը յուրաքանչյուր հավելված տեղադրելու համար, թարմացված հենարաններն անմիջապես տեսանելի կլինեն յուրաքանչյուր հավելվածին:

Վահանակի հավելվածում ես ավելացրեցի հետևյալ բաղադրիչը՝ օգտվողի մուտքագրումը դիտելու համար և նույնն արեցի նաև վճարային հավելվածում:

Այնուամենայնիվ, բացառությամբ ամենակարևոր հենակետերի, ցանկացած այլ տվյալ չպետք է փոխանցվի վեբ պորտալից դեպի միկրո առջևներ՝ չամրացված միացումը պահպանելու համար: