Բառը[Թաքցնել][Ցուցադրում]
- Միկրո ճակատային ճարտարապետության ներածություն
Micro frontend-ի առավելությունները +-
- Զարգացում արագ ինքնավար թիմերում
- Անհատական միկրո Frontend-ների փոքր կոդերի բազաները հանգեցնում են ավելի մաքուր կոդի
- Բարելավված հավելվածի կայունություն՝ չամրացված միացման պատճառով
- Անհատական առանձնահատկությունների փորձարկումն ավելի պարզ է դարձել
- Նվազեցված փաթեթի չափը հանգեցնում է էջի ավելի արագ բեռնման
- Տեխնոլոգիական անկախություն
- Եզրափակում
Միկրոծառայությունների գաղափարը վերջերս մեծ ուշադրության է արժանացել, և շատ ընկերություններ այն օգտագործում են մեծ, միաձույլ հետին պլանները վերացնելու համար:
Frontend-ի հետ նույն ճանապարհով գնալը դեռևս մարտահրավեր է շատ բիզնեսների համար, նույնիսկ եթե վեբ հավելվածների սերվերային կողմի կառուցման այս բաշխված ձևը քիչ թե շատ հուսալի է հետազոտության և կատարման առումով:
Իր սերտ կախվածության պատճառով հաճախորդի կողմից մոնոլիտը սովորաբար դժվարացնում է նոր առանձնահատկությունների ինտեգրումը, նոր տեխնոլոգիաների ընդունումը և առանձին բաղադրիչների մասշտաբը:
Այս և այլ մարտահրավերները դրդել են frontend-ի ծրագրավորողներին հետաքննել միկրոծառայությունների միջոցով:
Արդյունքում, մշակվել է բոլորովին նոր ճարտարապետական ռազմավարություն, որը հայտնի է որպես միկրո ֆրոնտ՝ վեբ կայքերի և վեբ հավելվածների առջևի շերտ ստեղծելու համար:
Տերմինն առաջին անգամ օգտագործվել է 2016 թվականին, և այդ ժամանակից ի վեր այն մեծ ուշադրություն է գրավել լավ պատճառով:
Այս հոդվածը կտա ընդհանուր պատկերացում այն մասին, թե ինչ են միկրո ֆրոնտենդները և դրանց լուծումը: այն աշխատում է, ինչպես նաև դրական և բացասական կողմեր:
Միկրո ճակատային ճարտարապետության ներածություն
Front-end-ի զարգացման ժամանակակից մեթոդը, որը կոչվում է micro-frontend ճարտարապետություն, բաժանում է ա վեբ հավելված փոքր, անկախ մասերի:
Վերջնական օգտագործողի համար այս մասերը թվում է մեկ միավոր, նույնիսկ եթե դրանք կառուցվել են ինքնուրույն, ապա միավորվել:
Այն տարբերությամբ, որ միկրո ճակատները վերաբերում են առցանց լուծումների ոչ թե սերվերի, այլ հաճախորդի կողմին, դրանց հիմքում ընկած հիմնավորումը նույնական է միկրոծառայությունների հետ:
Վեբ վրա հիմնված բարդ արտադրանքներ պատրաստելն առավել խելամիտ է միկրո առջևի մոտեցում օգտագործելիս:
Micro frontends-ը, ի տարբերություն ավելի սովորական առջևի մոնոլիտի, բազմաթիվ թիմերի հնարավորություն է տալիս առանձին համագործակցել տարբեր ծրագրային նախագծերի վրա:
Ծրագրավորողները կարող են ստեղծել վեբ հավելվածներ ավելի արագ և ավելի լայնածավալությամբ և պահպանելիությամբ՝ օգտագործելով այս ճարտարապետական դիզայնը:
Պարզ ասած, յուրաքանչյուր միկրո ֆրոնտենդ ընդամենը կոդ է վեբ էջի առանձին բաղադրիչի համար:
Այս հատկանիշները վերահսկվում են առանձին թիմերի կողմից, որոնցից յուրաքանչյուրը մասնագիտացած է որոշակի ոլորտում կամ նպատակի մեջ:
Մոնոլիտ ընդդեմ Microservices ընդդեմ Micro frontend ճարտարապետության
Մտածեք տեղափոխվելու մասին: Արդյո՞ք ձեզ համար ավելի պարզ կլինի ամեն ինչ կազմակերպել մի շարք փոքրիկ, հմուտ պիտակավորված տուփերի մեջ և տեղափոխել յուրաքանչյուրը առանձին, թե՞ ամբողջ անձնակազմը հավաքել մեկ հսկայական տուփի մեջ և տեղափոխել այն նոր վայր:
Ակնհայտ լուծումը կա.
Այս անալոգիան համեմատում է վեբ հավելվածների երկու տարբեր ճարտարապետությունները՝ մոնոլիտները և միկրոծառայությունները (նաև հայտնի են որպես միկրո ֆրոնտներ):
Միաձույլ ճարտարապետություն
Հնարավոր է, որ կարողանաք հիշել «հին լավ օրերը», երբ ամբողջական հավելվածը ստեղծվեց որպես միասնական, միասնական կազմավորում: Նման մեթոդը կոչվում է մոնոլիտ, որը հին տերմին է մեծ քարե բլոկների համար:
Սա իմաստ ունի:
Միաձույլ համակարգերն ունեն փոխկապակցված տարրեր: Հետևաբար, եթե ցանկանում եք ինչ-որ բան փոփոխել կամ ավելացնել նոր գործառույթ, հնարավոր է, որ ամբողջ համակարգը կարող է կոտրվել:
Չնայած այն հնացած է, երբեմն այն դեռ գոյություն ունի: Այո, մենք տեղյակ ենք ձեր ներկայիս արտահայտությունից։
Կոդի բազայի կոնցեպտուալ բաժանումը երկու տարբեր բաղադրիչների՝ ճակատային (հաճախորդի կողմից) և հետին մասի (սերվերի կողմ)- դարձավ անխուսափելի, քանի որ նոր տեխնոլոգիաները զարգացան և ծրագրային արտադրանքներն ավելի բարդացան:
Գործողության ամենահայտնի մեթոդն այժմ մտահոգությունների տարանջատումն է ներկայացման շերտի միջև, որի հետ շփվում է վերջնական օգտագործողը և այն ամենը, ինչ տեղի է ունենում հետին պլանում:
Նրան անհրաժեշտ է ծրագրային ապահովման ինժեներական երկու թիմ՝ առաջնային թիմով, որը կառուցում է վիզուալ բաղադրիչները, իսկ հետևի թիմը կառուցում է վեբ ծառայությունները, բիզնես տրամաբանությունը, տվյալների հասանելիությունը, ինտեգրումները և այլն:
Այնուամենայնիվ, չնայած այս տարանջատմանը, այս ռազմավարությունն իր բնույթով դեռևս մնում է միաձույլ։
Հիմնական փոփոխությունն այն է, որ մենք այժմ ունենք կոդի երկու զգալի բլոկ՝ ճակատը և հետին մասը, մեկ հսկայական հավելվածի փոխարեն: Պարտադիր չէ, որ մոնոլիտ ճարտարապետությունները սարսափելի լինեն. նրանք ունեն մի քանի առավելություններ, այդ թվում
- Պարզ և արագ մշակում փոքր հավելվածների համար՝ մեկ կոդային բազայով և շատ պարզ դիզայնով;
- Փորձարկումն ու վրիպազերծումը շատ պարզ են, քանի որ բոլոր ծածկագրերը գտնվում են մեկ վայրում, ինչը հեշտացնում է թիմի համար հարցումների հոսքին հետևելը և սխալների հայտնաբերումը.
- Հավելվածի մշակման սկզբում ծախսերն ավելի էժան են, քանի որ ոչ ենթակառուցվածքի ծախսերը, ոչ էլ զարգացման ծախսերը չեն կատարվում, քանի դեռ նոր հնարավորություններ չեն ավելացվել:
Այս ռազմավարության թերությունները արտացոլված են
- Սահմանափակ տեղակայման ճկունություն – թիմերը պետք է սպասեն, եթե նրանցից միայն մի քանիսն են աշխատում նախագծի վրա, և ամեն անգամ, երբ դուք թարմացնում եք կոդը, նոր տեղակայում է պահանջվում.
- Նոր տեխնոլոգիաների ընդունումը դժվար է, քանի որ դրա համար անհրաժեշտ է վերաշարադրել զգալի մասը, եթե ոչ ամբողջ նախագիծը:
- Երբ մշակողների թիվը մեծանում է, կոդի համակարգը դառնում է սերտորեն կապված, բարդ և դժվար է կառավարել ու հասկանալ:
- Կազմակերպչական խնդիրներ. թիմի յուրաքանչյուր անդամ պետք է օգտագործի գրադարանների նույն տարբերակը և զեկուցի ցանկացած փոփոխության մասին, եթե շատ թիմեր աշխատում են մոնոլիտ նախագծի վրա:
- Մտահոգություններ մասշտաբայնության հետ կապված. քանի որ ծրագրի բաղադրիչները փոխկապակցված են, դրանց առանձին մասշտաբը դժվարություններ է առաջացնում, որոնք հանգեցնում են զգալի պարապուրդի և ավելի մեծ ծախսերի:
- Ծրագրի բարդ տրամաբանությունը կարող է դժվար ըմբռնել թիմի նոր անդամների համար, հատկապես, եթե ինժեներները, ովքեր սկզբում աշխատել են դրա վրա, այլևս չեն աշխատում:
Միկրոծառայությունների և նրանց մերձավոր ազգականների և միկրո ֆրոնդենտների զարգացումը լուծեց մոնոլիտ համակարգերի առաջնային խնդիրները:
Միկրոծառայությունների ճարտարապետություն
Ճարտարապետական մեթոդը, որը հայտնի է որպես միկրոսերվիսներ, թույլ է տալիս ստեղծել շատ թույլ կապակցված և ինքնուրույն տեղակայվող փոքր բաղադրիչներ կամ ծառայություններ, որոնք կազմում են հավելվածի հետին մասը:
Յուրաքանչյուր ծառայություն ունի իր կոդերի բազան, CI/CD խողովակաշարերը, DevOps ընթացակարգերը և դրանց գործարկման գործընթացները:
Դուք կարող եք տեսնել, որ մոնոլիտ հետնամասի թիմը բաժանված է առանձին թիմերի՝ նայելով վերևի նկարին:
Յուրաքանչյուրն առանձին-առանձին կենտրոնանում է հավելվածի տարբեր ասպեկտների վրա (օրինակ՝ ապրանքի ծառայությունը, որոնման ծառայությունը և վճարային ծառայությունը):
Ծառայությունների միջև հաղորդակցությունը տեղի է ունենում հաստատված արձանագրությունների միջոցով, որոնք հայտնի են որպես API-ներ, ինչպիսիք են թեթև REST API արձանագրությունը, որն օգտագործում է հարցում-պատասխանի համաժամանակյա ձևեր:
Մեկ այլ տարբերակ է օգտագործել ասինխրոն հաղորդակցությունը՝ օգտագործելով Kafka-ի նման ծրագրակազմը, որն առաջարկում է հրապարակել/բաժանորդագրվել հաղորդակցման կառույցներ և իրադարձություններ:
Microservices-ը ինտեգրվում է frontend-ի հետ Frontend-ի (BFF) ծառայության կամ API Gateway-ի միջոցով ցանցի միջոցով: BFF-ն առաջարկում է հարմարեցված API յուրաքանչյուր հաճախորդի համար, մինչդեռ API Gateways-ը տալիս է մուտքի մեկ կետ միկրոծառայությունների հավաքածուի համար:
Բայց նույնիսկ ինքնավար հետին բաղադրամասերի և նրանց տրամադրած բոլոր առավելությունների դեպքում, ճակատային մասը դեռևս մոնոլիտ է:
Հետևաբար, սա այն վայրն է, որտեղ օգտակար են միկրո ճակատները:
Միկրո ճակատների ճարտարապետություն
Միկրոծառայությունների նման, որտեղ թույլ կապակցված բաղադրիչները կառավարվում են մի քանի թիմերի կողմից, միկրո ճակատային ճարտարապետությունը կիրառում է հայեցակարգը բրաուզերի վրա:
Այս վեբ հավելվածների օգտատիրոջ միջերեսները հետևում են այս կառուցվածքին, որը բաղկացած է որոշակիորեն ինքնավար բաղադրիչներից:
Թիմերը ստեղծվում են նաև հաճախորդի կարիքների կամ օգտագործման դեպքերի հիման վրա, այլ ոչ թե հատուկ փորձաքննության կամ տեխնոլոգիայի:
Հետևաբար, թիմերը ներգրավված են միկրոծառայությունների և միկրոֆրոնտենդ նախագծերում:
- ուղղահայաց կտրատված. քանի որ նույն նախագծի վրա աշխատում են նաև ճակատային ծրագրավորողներ, տվյալների փորձագետներ, հետին պլանի ինժեներներ, QA ինժեներներ և այլն, նրանք ստեղծում են իրենց առանձնահատկությունները օգտագործողի ինտերֆեյս տվյալների բազաներին; և
- խաչաձև ֆունկցիոնալ – թիմի յուրաքանչյուր անդամ իր փորձով ներդնում է խմբին:
Թիմերը կարող են նաև ընտրել տեխնոլոգիական փաթեթը, որը լավագույնս համապատասխանում է իրենց բիզնեսի կոնկրետ գծին:
Մեկ թիմ կարող է օգտագործել React-ը՝ իր հատվածը ծրագրավորելու համար: Մեկ այլ թիմ ստեղծում է նոր Angular տարբերակ: Vue.js-ը նման օրինակ է:
Micro frontends-ը օգտագործվում է հարակից միկրոծառայությունների հետ համատեղ՝ մոնոլիտների հետ կապված խնդիրների լուծման համար: Ռազմավարությունն առաջարկում է հետևյալ առավելությունները.
- Տեխնոլոգիաների ազատություն. Frontend-ի ինժեներները կարող են ընտրել JavaScript-ի այլընտրանքային շրջանակներ, գործարկման ժամանակի միջավայրեր և տեխնոլոգիական ամբողջ փաթեթներ՝ կախված ընկերության կարիքներից: Ի լրումն հնացած ճարտարապետության, կարող է կիրառվել թարմ շրջանակ:
- Հնարավոր է ճկունության ավելի մեծ աստիճան, քանի որ յուրաքանչյուր միկրո ֆրոնետ ինքնուրույն է և կարող է մշակվել, փորձարկվել, տեղակայվել և արդիականացվել առանձին: Արդյունքում, եթե մի թիմ աշխատում է ֆունկցիայի վրա և առաջ է քաշել սխալների շտկում, իսկ մյուս թիմը պետք է ավելացնի իր սեփական հնարավորությունը, նրանք կարիք չունեն սպասել, որ առաջին թիմը կատարի իր առաջադրանքը:
- Ինքնավար թիմեր և համակարգեր. Յուրաքանչյուր արտադրանքի թիմ և, հետևաբար, յուրաքանչյուր հատկանիշ կարող է գործել ուրիշներից քիչ կախվածությամբ, ինչը թույլ է տալիս նրան շարունակել աշխատել նույնիսկ այն դեպքում, երբ մոտակա բաղադրիչներն անհասանելի են:
- Բազմաթիվ, ավելի փոքր կոդերի բազաներ. միկրո ֆրոնտներից յուրաքանչյուրը կունենա իր սեփական, ավելի կառավարելի, փոքր կոդերի բազան: Ավելի քիչ մարդիկ կկենտրոնանան UI-ի որոշակի բաղադրիչի վրա, կպարզեցնեն կոդի ակնարկները և կբարելավեն ընդհանուր կազմակերպությունը:
- Հավելվածների պարզ մասշտաբավորում. Միկրո ճակատների մեկ այլ առավելություն յուրաքանչյուր հատկանիշն առանձին չափելու հնարավորությունն է: Ի տարբերություն մոնոլիտների, որտեղ ամբողջ ծրագիրը պետք է մասշտաբավորվի ամեն անգամ, երբ նոր հնարավորություն է ավելացվում, սա ամբողջ գործընթացը դարձնում է ավելի արդյունավետ ինչպես ժամանակի, այնպես էլ գումարի առումով:
Ինչպե՞ս է աշխատում micro frontend-ը:
Ինչպես նախկինում ասել ենք, թիմերը ուղղահայաց կազմակերպված են միկրո ճակատային ճարտարապետության ներսում, ինչը նշանակում է, որ դրանք առանձնացված են տիրույթի գիտելիքներով կամ նպատակներով և պատասխանատու են սկզբից մինչև վերջ կոնկրետ արտադրանքի համար:
Այն կարող է ունենալ մեկ կամ երկու հետնամասային միկրոսերվիսներ, ինչպես նաև փոքր ճակատ: Ավելի մանրամասն, եկեք ուսումնասիրենք այս վիզուալ տարրի բնութագրերը, փոխազդեցությունը այլ UI բաղադրիչների հետ և ներառումը գլխավոր էջում:
Միկրո ճակատը կարող է լինել
- մի ամբողջ էջ (օրինակ՝ ապրանքի մանրամասների էջ) կամ
- էջի բաժիններ, որոնք կարող են օգտագործվել այլ թիմերի կողմից, ինչպիսիք են վերնագրերը, ստորոտները և որոնման տողերը:
Դուք կարող եք մեծ վեբ կայքը բաժանել մի քանի էջի տեսակների և յուրաքանչյուր տիպ տալ հատուկ աշխատակցի՝ աշխատելու համար:
Այնուամենայնիվ, մի քանի բաղադրիչներ հաճախ հանդիպում են բազմաթիվ էջերում, ինչպիսիք են վերնագրերը, ստորագրերը, առաջարկների բլոկները և այլն: Օրինակ, առաջարկների բլոկը կարող է ներառվել գլխավոր էջում, ապրանքի մանրամասների էջում կամ նույնիսկ վճարման էջում:
Ըստ էության, թիմերը կարող են ստեղծել կտորներ, որոնք այլ թիմերը կարող են օգտագործել իրենց էջերում:
Միկրո ճակատները, սակայն, կարող են տեղակայվել առանձին՝ որպես տարբեր նախագծեր՝ ի տարբերություն բազմակի օգտագործման բաղադրիչների:
Այս ամենը ֆանտաստիկ է թվում, բայց միասնական ինտերֆեյս ստեղծելու համար էջերն ու հատվածները պետք է ինչ-որ կերպ համադրվեն:
Սա պահանջում է ճակատային ինտեգրում, որը կարող է իրականացվել մի շարք ռազմավարությունների միջոցով, ներառյալ երթուղին, կոմպոզիցիան և հաղորդակցությունը (տես վերևի գրաֆիկը):
Routing
Երբ մեկ թիմի կողմից վերահսկվող էջի ծառայությունը պահանջվում է մեկ այլ թիմի պատկանող էջ մուտք գործելու համար, երթուղավորումն օգտակար է էջի մակարդակի ինտեգրման համար:
Յուրաքանչյուր միկրո ֆրոնտենդ մշակվում է որպես մեկ էջանոց հավելված: Պարզ HTML հղումները կարող են օգտագործվել երթուղիներ տրամադրելու համար:
Օգտագործողը կարող է ստիպել զննարկիչին ներբեռնել թիրախային նշումը սերվերից և փոխարինել ընթացիկ էջը նորով` սեղմելով հիպերհղումների վրա:
Հավելվածի կեղևը HTML, CSS և JavaScript-ի նվազագույն նվազագույնն է, որն ապահովում է միջերեսը: Նույնիսկ եթե սերվերից պահանջվող բովանդակության տվյալները դեռ սպասում են, օգտվողն անմիջապես ստանում է ստատիկ ցուցադրվող էջ: Կենտրոնական հավելվածի կեղևը ծառայում է որպես ծնողական հավելված տարբեր թիմերի կողմից ստեղծված մեկ էջանոց հավելվածների համար:
Անկախ օգտագործվող գրադարանից կամ շրջանակից, մետա-շրջանակները թույլ են տալիս միաձուլել տարբեր էջերը մեկում:
կազմը
Կոմպոզիցիան կտորների դասավորության գործընթացն է, որպեսզի դրանք տեղավորվեն էջի համապատասխան բացատներում: Շատ դեպքերում, թիմը, որը տեղակայում է էջը, անմիջապես չի վերցնում հատվածի բովանդակությունը:
Փոխարենը, այն տեղադրում է տեղապահ կամ նշիչ, որտեղ հատվածը պետք է լինի նշագրման մեջ:
Օգտագործելով այլ կոմպոզիցիայի գործընթաց, վերջնական հավաքումը կատարվում է: Կազմը կարելի է բաժանել երկու հիմնական կատեգորիայի՝ հաճախորդի կողմից և սերվերի կողմից:
Հաճախորդի կողմից կազմըՎեբ զննարկիչը օգտագործվում է HTML նշում ստեղծելու և խմբագրելու համար: Յուրաքանչյուր միկրո ֆրոնտ ունի հնարավորություն փոխելու և ցուցադրելու իր նշագրումը էջի մնացած մասերից առանձին:
Վեբ բաղադրիչները, օրինակ, թույլ են տալիս իրականացնել այս տեսակի շինարարություն:
Ծրագրվում է յուրաքանչյուր հատվածը վերածել վեբ բաղադրիչի, որը կարող է ինքնուրույն տեղադրվել որպես a.js ֆայլ, որից հետո հավելվածները կարող են բեռնել և մատուցել դրանք թեմայի դասավորության մեջ իրենց համար նախատեսված տարածքներում:
Վեբ բաղադրիչները կախված են HTML-ից և DOM API-ից, որոնք կարող են օգտագործել այլ ճակատային շրջանակները, ինչպես նաև տվյալների ուղարկման և ստացման ստանդարտ մեթոդը՝ հենակետերի և իրադարձությունների միջոցով:
Սերվերի կողմի կազմըԱյս դիզայնով UI-ի մասերը համակցվում են սերվերի վրա, ինչի արդյունքում ամբողջովին ձևավորված էջն ուղարկվում է հաճախորդի կողմից՝ արագացնելով բեռնումը:
Հավաքումը հաճախ իրականացվում է առանձին ծառայության կողմից, որը տեղակայված է վեբ բրաուզերի և վեբ սերվերների միջև: CDN-ն ծառայության մեկ օրինակ է (բովանդակության առաքման ցանց):
Դուք կարող եք ընտրել մեկը կամ երկուսի համադրությունը՝ կախված ձեր կարիքներից:
Micro frontend կապի օրինաչափություններ
Micro-frontend ճարտարապետությունը լավագույնս աշխատում է, երբ տարբեր բաղադրիչների միջև փոխազդեցությունը քիչ է կամ բացակայում է: Micro frontend-ները երբեմն պետք է խոսեն միմյանց հետ և կիսվեն տեղեկատվությունը: Ահա մի քանի պոտենցիալ օրինաչափություններ, որոնք կարող են հանգեցնել դրան:
- Վեբ աշխատողներԱռցանց աշխատողը մեխանիզմ է, որը թույլ է տալիս վեբ բովանդակությունը գործարկել JavaScript-ը ֆոնային պլանում՝ անկախ այլ սկրիպտներից և առանց էջի արագության վրա ազդելու: Յուրաքանչյուր միկրո հավելվածի համար կտրամադրվի եզակի աշխատանքային API: Այս առավելությունն այն է, որ ժամանակատար աշխատանքը կարող է կատարվել մեկ այլ թեմայում, ինչը հնարավորություն է տալիս UI շարանը շարունակել առանց դանդաղեցնելու կամ դադարեցնելու:
- Իրադարձությունների թողարկիչԱյս դեպքում շատ բաղադրիչներ շփվում են միմյանց հետ՝ լսելով և ազդելով այն բաղադրիչների վիճակի ցանկացած փոփոխության վրա, որոնց բաժանորդագրված են: Մյուս միկրո ֆրոնտենդները, որոնք բաժանորդագրվել են այդ հատուկ իրադարձությանը, արձագանքում են, երբ միկրո ֆրոնդենդն անջատում է այդ իրադարձությունը: Իրադարձությունների թողարկիչը, որը ներդրվել է յուրաքանչյուր միկրո-ճակատում, դա իրագործելի է դարձնում:
- Հետադարձ զանգեր և հենարաններԱյս բաժնում դուք սահմանում եք մայր բաղադրիչ և զավակ բաղադրիչներ: Հաղորդակցությունը կազմակերպվում է ծառանման կառույցի: Ծնողական բաղադրիչներն օգտագործում են հենարաններ՝ տվյալները որպես գործառույթներ բաղադրիչի ծառից դեպի երեխայի բաղադրիչներ փոխանցելու համար: Իր հերթին, երեխան կարող է արդյունավետորեն զգուշացնել ծնողին, երբ որևէ բան տեղի է ունենում նրանց վիճակում՝ արձագանքելով հետզանգերին: React-ն օգտագործում է այս ռեժիմը:
Micro frontend-ի առավելությունները
Զարգացում արագ ինքնավար թիմերում
Անկախ թիմը կարող է ստեղծել վեբ հավելվածի կամ վեբկայքի յուրաքանչյուր մաս՝ օգտագործելով միկրո դիմային մեթոդ:
Յուրաքանչյուր թիմ լիովին ինքնավար է, ինչը նշանակում է, որ պատասխանատու է բաղադրիչի մշակման ողջ ցիկլով` սկսած գաղափարից մինչև թողարկում և հետարտադրական:
Բացի այդ, դա ենթադրում է, որ տարբեր թիմեր կարող են անխափան համագործակցել՝ միաժամանակ աշխատելով նույն նախագծի վրա:
Հետևաբար, թողարկման ցիկլերը զգալիորեն ավելի արագ են, քան կլինեին առջևի մոնոլիտների դեպքում:
Անհատական միկրո Frontend-ների փոքր կոդերի բազաները հանգեցնում են ավելի մաքուր կոդի
Մոնոլիտ առջևի ծայրերն ունեն մեծ, անգործունակ ծածկագրեր, որոնք ժամանակի ընթացքում դառնում են ավելի քաոսային և դժվար է կառավարել:
Միկրո ճակատները լուծում են այս խնդիրը: Յուրաքանչյուր միկրո frontend-ի սկզբնական կոդը ավելի կառավարելի է, քանի որ այն ավելի փոքր է, պարզ և ավելի կոմպակտ:
Որպես հետևանք, ընդհանուր վեբ լուծումը շահում է ավելի մաքուր կոդից:
Բարելավված հավելվածի կայունություն՝ չամրացված միացման պատճառով
Վեբ լուծումը հազվադեպ կարելի է բաժանել ամբողջովին անկախ մասերի: Հետևաբար, միկրո ճակատները խոսում են միմյանց հետ:
Այնուամենայնիվ, բաղադրիչների միջև յուրաքանչյուր կապ կարևոր է, չնայած թույլ կապին:
Մեկ բաղադրիչի խափանումը քիչ կամ բացակայում է բոլոր մյուս բաղադրիչների աշխատանքի վրա, ինչը ապահովում է վեբ լուծման ուժեղացված կայունությունը:
Անհատական առանձնահատկությունների փորձարկումն ավելի պարզ է դարձել
Այս օգուտը բխում է միկրո ճակատների բնութագրերից: Այս ճարտարապետական դիզայնի հիման վրա վեբ լուծման հաճախորդի կողմը մոդուլային է, և յուրաքանչյուր մոդուլ ինքնավար է:
Արդյունքում, օգտատիրոջ միջերեսի փոքր մասի գնահատումն ինքնին ավելի հեշտ է թիմի համար անել, քան զանգվածային մոնոլիտի փորձարկումը:
Նվազեցված փաթեթի չափը հանգեցնում է էջի ավելի արագ բեռնման
Հատկանիշներով հարուստ մոնոլիտ վեբ համակարգերում բեռնման հետաձգման հիմնական պատճառներից մեկը JavaScript փաթեթի չափն է: Մյուս կողմից, միկրո ճակատային մոտեցումը հեշտացնում է էջի բեռնման ժամանակը նվազեցնելը:
Բրաուզերը չպետք է մի քանի անգամ ներբեռնի անհարկի կոդ, քանի որ վեբ էջը բաղկացած է մի քանի փոքրիկ փաթեթներից: Արդյունքում, էջի կատարումը և բեռնման ժամանակները մեծանում են:
Տեխնոլոգիական անկախություն
բազմապատիկ ճակատային շրջանակներ կարող է օգտագործվել ծրագրավորողների կողմից՝ միկրո-առանցքային ճարտարապետությամբ միասնական առցանց լուծում ստեղծելու համար:
Քանի որ յուրաքանչյուր բաղադրիչ ինքնավար է, այն կարող է կառուցվել՝ օգտագործելով այն տեխնոլոգիան, որը լավագույնս համապատասխանում է թիմի առաջադրանքներին:
Բնականաբար, ծրագրավորողները պետք է զգույշ լինեն ծրագրային ապահովման նախագծի համար շրջանակներ ընտրելիս, որոնց ղեկավարում են, և այլ թիմերի հետ խորհրդակցությունները դեռևս խստորեն խորհուրդ են տրվում:
Այնուամենայնիվ, զրոյական հավանականություն կա, որ դուք ստիպված կլինեք օգտագործել հին շրջանակը հավելվածի կյանքի տևողության համար:
Micro Frontend-ի թերությունները
Համալիր վեբ լուծումների փորձարկումն ամբողջությամբ
Վեբ լուծման տարբեր մոդուլների փորձարկումը հեշտ է, երբ այն օգտագործում է միկրո-առանցքային ճարտարապետություն: Այնուամենայնիվ, այն տարբերվում է վեբ հավելվածը որպես ամբողջություն գնահատելուց:
Շարունակելուց առաջ ստուգեք, որ բոլոր մասերը գործում են այնպես, ինչպես նախատեսված է: Սա կարող է դժվար լինել, քանի որ միկրո ֆրոնտենդները գործում են անկախ և ունեն առանձին առաքման գործընթացներ:
Թանկ սկզբնական ներդրումներ
Միկրո ճակատային զարգացումները սովորաբար պահանջում են զգալի ֆինանսական ծախսեր: Բազմաթիվ առաջնային թիմեր հավաքելը և պահելը թանկ է:
Բացի այդ, ձեզ հարկավոր կլինի ղեկավար անձնակազմ՝ աշխատանքը կազմակերպելու համար, համոզվելու, որ ամեն ինչ համակարգված է և երաշխավորում է գերազանց թիմային հաղորդակցություն:
Մշակման և տեղակայման բարդությունը
Մշակման և տեղակայման ընթացակարգերը կարող են ավելի բարդանալ միկրո-առանցքային դիզայնի արդյունքում:
Օրինակ, նույն նախագծի վրա աշխատող անկախ զարգացման թիմերի լուծումը կարող է խճճված լինել չափազանց շատ բաղադրիչներով, ինչը կարող է խնդիրներ առաջացնել տեղակայման փուլում:
Բոլոր մոդուլների ճիշտ հավաքումը և դրանց սահուն ինտեգրումը ընդհանուր սխեմայի մեջ նույնպես միշտ չէ, որ պարզ է. այս աշխատանքը սովորաբար պահանջում է բոլոր կախվածությունների մանրակրկիտ ըմբռնումը:
Օգտագործողի փորձի մեջ համահունչության պահպանման խնդիրներ
Օգտվողի հետևողական ինտերֆեյսի պահպանումը դժվար է, երբ թիմերը առանձին են աշխատում ծրագրաշարի մի քանի մասերի վրա:
Վեբ լուծումը պետք է համօգտագործվի նախագծի բոլոր մշակողների կողմից: Հակառակ դեպքում ճանապարհին կարող են շատ հակասություններ լինել։
Եզրափակում
Micro frontends-ը, ժամանակակից ճարտարապետական դիզայնը, կարող է մեծապես բարելավել միկրոծառայությունների վրա հիմնված վեբ զարգացման լայնածավալ նախագծերի արդյունավետությունը:
Այն ծրագրավորողներին հնարավորություն է տալիս ամբողջական լուծումը բաժանել առանձին մասերի, որոնք կարող են ստեղծվել մի քանի ինքնավար թիմերի կողմից: Սրանից հետևում են բազմաթիվ առավելություններ, այդ թվում՝ գործառույթների ավելի արագ ներդրում, առանձին մոդուլների ավելի հեշտ փորձարկում և ավելի անխափան թարմացումներ:
Բայց կան որոշ դժվարություններ նաև միկրո ճակատների հետ կապված:
Հավելվածի համապարփակ փորձարկումը, օրինակ, կարող է դժվար լինել:
Բացի այդ, քանի որ անհրաժեշտ է ինժեներների և ադմինիստրատորների մեծ թիմ, միկրո ֆրոնտենդ նախագծերը շատ թանկ են:
Հետևաբար, նախքան որոշում կայացնելը, դուք պետք է հաշվի առնեք ձեր բիզնեսի բոլոր բաղադրիչները։
Վլադիմիր Չամայ
Ինչ-որ կերպ ես չհասկացա, թե ինչ սկզբունքով է աշխատում առջևի առանձին բաղադրիչների միջև շփումը: Ես չեմ հասկանում, թե ինչպես եք ուզում միացնել բաղադրիչները, որոնք ստեղծված են տարբեր շրջանակներում: Այդ մասին հոդվածում ոչինչ չկա։ Իրադարձությունների և ունկնդիրների համակարգն ինձ թվում է երկրի վրա դժոխք: Ինչպե՞ս պետք է դա պատկերացնենք։