Змест[Схаваць][Паказаць]
- Уводзіны ў архітэктуру мікрафрантальнага інтэрфейсу
Плюсы інтэрфейсу Micro +-
- Развіццё ў хутка аўтаномных камандах
- Меншыя кодавыя базы асобных мікрафрантальных праграм прыводзяць да больш чыстага кода
- Палепшаная стабільнасць праграмы з-за слабай сувязі
- Тэставанне асобных функцый стала прасцей
- Паменшаны памер пакета прыводзіць да больш хуткай загрузкі старонкі
- Тэхналагічная незалежнасць
- заключэнне
Ідэя мікрасэрвісаў нядаўна прыцягнула вялікую ўвагу, і многія фірмы выкарыстоўваюць яе, каб пазбавіцца ад вялікіх маналітных бэкэндаў.
Ісці тым жа шляхам з інтэрфейсам па-ранейшаму з'яўляецца праблемай для многіх прадпрыемстваў, нават калі гэты размеркаваны спосаб пабудовы сервернага боку вэб-прыкладанняў больш-менш надзейны з пункту гледжання даследаванняў і выканання.
З-за цеснай залежнасці маналіт на баку кліента звычайна ўскладняе інтэграцыю новых функцый, прыняцце новых тэхналогій і маштабаванне асобных кампанентаў.
Гэтыя і іншыя праблемы падштурхнулі распрацоўшчыкаў інтэрфейсу да вывучэння выкарыстання мікрасэрвісаў.
У выніку была распрацавана зусім новая архітэктурная стратэгія, вядомая як microfrontend, для стварэння інтэрфейснага ўзроўню вэб-сайтаў і вэб-прыкладанняў.
Тэрмін быў упершыню выкарыстаны ў 2016 годзе, і з таго часу ён прыцягнуў шмат увагі для добрай справы.
Гэты артыкул дасць агульнае разуменне таго, што такое мікрафрантавыя інтэрфейсы і якія праблемы яны вырашаюць. гэта працуе, а таксама плюсы і мінусы.
Уводзіны ў архітэктуру мікрафрантальнага інтэрфейсу
Сучасны метад інтэрфейснай распрацоўкі, які называецца мікрафрантальнай архітэктурай, падзяляе a вэб-прыкладанне на невялікія самастойныя часткі.
Для канчатковага карыстальніка гэтыя часткі выглядаюць як адно цэлае, нават калі яны былі пабудаваны незалежна адзін ад аднаго, а затым сабраны разам.
З той розніцай, што мікрафрантавыя інтэрфейсы адносяцца да кліенцкага, а не да сервернага боку інтэрнэт-рашэнняў, абгрунтаванне, якое ляжыць у іх аснове, ідэнтычнае таму, што ёсць у мікрасэрвісаў.
Стварэнне складаных вэб-прадуктаў мае найбольшы сэнс пры выкарыстанні мікраінтэрфейсу.
Мікрафрантальныя інтэрфейсы, у адрозненне ад больш звычайнага інтэрфейснага маналіту, дазваляюць многім камандам асобна супрацоўнічаць над рознымі праграмнымі праектамі.
З дапамогай гэтага архітэктурнага дызайну праграмісты могуць ствараць вэб-праграмы хутчэй і з большай маштабаванасцю і зручнасцю абслугоўвання.
Прасцей кажучы, кожны мікрафрантэнд - гэта проста частка кода для асобнага кампанента вэб-старонкі.
Гэтыя функцыі кантралююцца асобнымі камандамі, кожная з якіх спецыялізуецца на пэўнай галіны або мэты.
Маналітная супраць мікрасэрвісаў супраць мікра інтэрфейснай архітэктуры
Падумайце пра пераезд. Ці будзе вам прасцей арганізаваць усё ў невялікія, пазначаныя спецыялістам скрынкі і перамясціць кожную паасобку, ці сабраць увесь персанал у адну велізарную скрынку і перавезці яе на новае месца?
Відавочнае рашэнне ёсць.
Гэтая аналогія параўноўвае дзве розныя архітэктуры вэб-прыкладанняў, маналіты і мікрасэрвісы (таксама вядомыя як мікраінтэрфейсы).
Маналітная архітэктура
Магчыма, вы зможаце ўспомніць «старыя добрыя часы», калі цэласнае прыкладанне стваралася як адзіная згуртаваная сутнасць. Такі метад называецца маналітам, што з'яўляецца старым тэрмінам для вялікага каменнага блока.
Гэта мае сэнс.
Маналітныя сістэмы маюць узаемазалежныя элементы. Такім чынам, калі вы хочаце нешта змяніць або дадаць новую функцыю, магчыма, што ўся сістэма можа зламацца.
Нягледзячы на тое, што ён састарэў, ён часам усё яшчэ існуе. Так, мы ведаем пра ваш цяперашні выраз.
Канцэптуальны падзел кодавай базы на два розныя кампаненты — інтэрфейс (кліенцкі) і бэкэнд (серверны) — стаў непазбежным па меры развіцця новых тэхналогій і ўскладнення праграмных прадуктаў.
Зараз самым папулярным метадам працы з'яўляецца раздзяленне праблем паміж узроўнем прэзентацыі, з якім узаемадзейнічае канечны карыстальнік, і ўсім, што адбываецца ў фонавым рэжыме.
Для гэтага патрэбныя дзве каманды распрацоўнікаў праграмнага забеспячэння: група інтэрфейсу стварае візуальныя кампаненты, а каманда сервераў стварае вэб-сэрвісы, бізнес-логіку, доступ да даных, інтэграцыю і г.д.
Аднак, нягледзячы на гэты падзел, гэтая стратэгія ўсё яшчэ застаецца маналітнай па сваёй прыродзе.
Галоўная змена заключаецца ў тым, што цяпер у нас ёсць два значныя блокі кода — інтэрфейс і сервер — замест аднаго вялізнага прыкладання. Маналітныя архітэктуры не павінны быць жахлівымі; яны маюць некалькі пераваг, у тым ліку
- Простая і хуткая распрацоўка для маленькіх прыкладанняў з адзінай базай зыходнага кода і вельмі простым дызайнам;
- Тэставанне і адладка вельмі простыя, таму што ўвесь код знаходзіцца ў адным месцы, што палягчае камандзе адсочванне патоку запытаў і выяўленне памылак;
- На ранніх стадыях распрацоўкі прыкладання выдаткі таннейшыя, паколькі ні выдаткі на інфраструктуру, ні выдаткі на распрацоўку не ўзнікаюць, пакуль не будуць дададзены новыя функцыі.
Недахопы гэтай стратэгіі адлюстраваны ў
- Абмежаваная гібкасць разгортвання - каманды павінны чакаць, калі толькі нешматлікія з іх працуюць над праектам, і новае разгортванне патрабуецца кожны раз, калі вы абнаўляеце код;
- Укараненне новых тэхналогій з'яўляецца складанай задачай, бо гэта патрабуе перапісвання значнай часткі, калі не ўсяго праекта.
- Калі колькасць распрацоўшчыкаў павялічваецца, сістэма кода становіцца цесна звязанай, складанай і цяжкай для кіравання і разумення.
- Арганізацыйныя пытанні - кожны член каманды павінен выкарыстоўваць адну і тую ж версію бібліятэк і паведамляць аб любых зменах, калі над маналітным праектам працуе шмат каманд.
- Праблемы з маштабаванасцю – паколькі кампаненты праекта ўзаемазвязаны, іх асобнае маштабаванне ўяўляе цяжкасці, якія прыводзяць да значнага часу прастою і большых выдаткаў.
- Новым членам каманды можа быць цяжка зразумець складаную логіку праекта, асабліва калі інжынеры, якія першапачаткова працавалі над ім, больш не працуюць.
Развіццё мікрасэрвісаў і іх блізкіх сваякоў, а таксама мікраінтэрфейсаў вырашала асноўныя праблемы маналітных сістэм.
Архітэктура мікрасэрвісаў
Архітэктурны метад, вядомы як мікрасэрвісы, дазваляе ствараць мноства слаба звязаных і разгортвальных меншых кампанентаў або сэрвісаў, якія складаюць бэкэнд прыкладання.
Кожны сэрвіс мае ўласную кодавую базу, канвееры CI/CD, працэдуры DevOps і працэсы для іх запуску.
Вы можаце ўбачыць, што маналітная бэкэнд-каманда падзелена на асобныя каманды, паглядзеўшы на малюнак вышэй.
Кожнае асобна засяроджана на розных аспектах прыкладання (напрыклад, сэрвіс прадукту, сэрвіс пошуку і сэрвіс аплаты).
Сувязь паміж службамі адбываецца праз устаноўленыя пратаколы, вядомыя як API, такія як палегчаны пратакол REST API, які выкарыстоўвае сінхронныя шаблоны запыту-адказу.
Іншы варыянт - выкарыстоўваць асінхронную сувязь з дапамогай праграмнага забеспячэння, напрыклад Kafka, якое прапануе камунікацыйныя структуры і падзеі для публікацыі/падпіскі.
Мікрасэрвісы інтэгруюцца з інтэрфейсам праз бэкэнд для службы інтэрфейсу (BFF) або шлюз API праз сетку. BFF прапануе індывідуальны API для кожнага кліента, у той час як шлюзы API даюць адзіную кропку доступу для калекцыі мікрасэрвісаў.
Але нават з аўтаномнымі бэкэнд-кампанентамі і ўсімі перавагамі, якія яны даюць, інтэрфейс па-ранейшаму застаецца маналітам.
Такім чынам, гэта тое, дзе мікра інтэрфейсы карысныя.
Архітэктура мікрафрантальных праграм
Падобна мікрасэрвісам, дзе слаба звязаныя кампаненты кіруюцца некалькімі групамі, архітэктура мікрафрантальнага інтэрфейсу прымяняе гэтую канцэпцыю да браўзера.
Гэтыя карыстальніцкія інтэрфейсы вэб-праграм прытрымліваюцца гэтай структуры, якая складаецца з у пэўнай ступені аўтаномных кампанентаў.
Каманды таксама ствараюцца з улікам патрэб кліентаў або варыянтаў выкарыстання, а не канкрэтных ведаў або тэхналогій.
Такім чынам, каманды ўдзельнічаюць у мікрасэрвісах і мікрапраектах інтэрфейсу.
- вертыкальна разрэзаны — паколькі над адным праектам таксама працуюць распрацоўшчыкі інтэрфейсу, эксперты па даных, інжынеры бэкэнда, інжынеры кантролю якасці і г.д., яны ствараюць свае функцыі з інтэрфейс карыстальніка да баз даных; і
- міжфункцыянальны - кожны член каманды ўносіць свой вопыт у групу.
Каманды таксама могуць выбраць набор тэхналогій, які лепш за ўсё адпавядае іх канкрэтнаму напрамку бізнесу.
Адна каманда можа выкарыстоўваць React для праграмавання свайго фрагмента. Іншая каманда стварае новую версію Angular. Vue.js - адзін з такіх прыкладаў.
Мікраінтэрфейсы выкарыстоўваюцца ў спалучэнні з адпаведнымі мікрасэрвісамі для вырашэння праблем, якія звычайна ўзнікаюць у каманд распрацоўшчыкаў з маналітамі. Стратэгія прапануе наступныя перавагі.
- Свабода тэхналогій: інтэрфейсныя інжынеры могуць выбіраць альтэрнатыўныя фрэймворкі JavaScript, асяроддзі выканання і цэлыя стэкі тэхналогій у залежнасці ад патрэбаў кампаніі. У дадатак да састарэлай архітэктуры можа быць ужыты новы фрэймворк.
- Большая ступень гнуткасці магчымая, паколькі кожны мікрафрантальны інтэрфейс аўтаномны і можа распрацоўвацца, тэставацца, разгортвацца і абнаўляцца асобна. У выніку, калі адна каманда працуе над функцыяй і выправіла памылку, а іншая каманда павінна дадаць сваю ўласную функцыю, ім не трэба чакаць, пакуль першая каманда выканае сваю задачу.
- Аўтаномныя каманды і сістэмы: кожная каманда прадукту і, адпаведна, кожная функцыя могуць працаваць практычна не залежна ад іншых, што дазваляе ёй працягваць працаваць, нават калі бліжэйшыя кампаненты недаступныя.
- Некалькі меншых кодавых баз: кожны з мікрафрантавых інтэрфейсаў будзе мець сваю ўласную, больш кіраваную, меншую кодавую базу. Менш людзей будуць засяроджвацца на пэўным кампаненце карыстацкага інтэрфейсу, спрашчаць агляд кода і паляпшаць агульную арганізацыю.
- Простае маштабаванне праграмы: яшчэ адна перавага мікраінтэрфейсаў - магчымасць маштабаваць кожную функцыю паасобку. У адрозненне ад маналітаў, дзе ўсю праграму трэба маштабаваць кожны раз, калі дадаецца новая функцыя, гэта робіць увесь працэс больш эфектыўным з пункту гледжання часу і грошай.
Як працуе мікра інтэрфейс?
Як мы ўжо заяўлялі раней, каманды вертыкальна арганізаваны ўнутры архітэктуры мікрафрантальнага інтэрфейсу, што азначае, што яны падзеленыя ведамі вобласці або мэтамі і нясуць адказнасць ад пачатку да канца за пэўны прадукт.
Ён можа мець адзін ці два бэкэнд-мікрасэрвісы, а таксама невялікі інтэрфейс. Давайце больш падрабязна разгледзім характарыстыкі гэтага візуальнага элемента, узаемадзеянне з іншымі кампанентамі карыстацкага інтэрфейсу і ўключэнне ў галоўную старонку.
Мікра інтэрфейс можа быць
- цэлая старонка (напрыклад, старонка з падрабязнай інфармацыяй пра прадукт) або
- раздзелы старонкі, якія могуць выкарыстоўвацца іншымі камандамі, такія як верхнія, ніжнія калонтытулы і панэлі пошуку.
Вы можаце падзяліць вялікі вэб-сайт на некалькі тыпаў старонак і перадаць кожны тып для працы пэўным супрацоўнікам.
Тым не менш, некалькі кампанентаў часта сустракаюцца на шматлікіх старонках, такіх як верхнія і ніжнія калонтытулы, блокі прапаноў і г.д. Блок прапаноў, напрыклад, можа быць уключаны на галоўную старонку, старонку з падрабязнай інфармацыяй пра прадукт ці нават на старонку афармлення замовы.
Па сутнасці, каманды могуць ствараць часткі, якія іншыя каманды могуць выкарыстоўваць на сваіх старонках.
Мікрапраграмы, аднак, могуць быць разгорнуты асобна як розныя праекты ў адрозненне ад шматразовых кампанентаў.
Усё гэта гучыць фантастычна, але каб стварыць уніфікаваны інтэрфейс, старонкі і фрагменты трэба неяк аб'яднаць.
Гэта патрабуе інтэрфейснай інтэграцыі, якая можа быць выканана з дапамогай розных стратэгій, уключаючы маршрутызацыю, кампазіцыю і сувязь (гл. графік вышэй).
Маршрутызацыя
Калі для доступу да старонкі, якая належыць іншай камандзе, патрабуецца абслугоўванне са старонкі, якая кантралюецца адной камандай, маршрутызацыя карысная для інтэграцыі на ўзроўні старонкі.
Кожны мікраінтэрфейс апрацоўваецца як аднастаронкавае прыкладанне. Простыя спасылкі HTML могуць быць выкарыстаны для забеспячэння маршрутызацыі.
Карыстальнік можа прымусіць браўзер загрузіць мэтавую разметку з сервера і замяніць бягучую старонку новай, пстрыкнуўшы па гіперспасылках.
Абалонка прыкладання - гэта мінімум HTML, CSS і JavaScript, які забяспечвае карыстацкі інтэрфейс. Нават калі даныя кантэнту, запытаныя з сервера, усё яшчэ чакаюць, карыстальнік адразу ж атрымлівае статычную адлюстраваную старонку. Цэнтральная абалонка прыкладання служыць у якасці бацькоўскага прыкладання для аднастаронкавых прыкладанняў, створаных рознымі камандамі.
Незалежна ад бібліятэкі або фрэймворка, якія выкарыстоўваюцца, метафреймворкі дазваляюць аб'ядноўваць розныя старонкі ў адну.
кампазіцыя
Кампазіцыя - гэта працэс размяшчэння частак у адпаведных месцах на старонцы. У большасці выпадкаў каманда, якая разгортвае старонку, не адразу атрымлівае змесціва фрагмента.
Замест гэтага ён размяшчае запаўняльнік або маркер там, дзе фрагмент павінен быць у разметцы.
Канчатковая зборка выконваецца з дапамогай іншага працэсу кампазіцыі. Кампазіцыю можна падзяліць на дзве асноўныя катэгорыі: на баку кліента і на баку сервера.
Кампазіцыя на баку кліента: вэб-браўзер выкарыстоўваецца для стварэння і рэдагавання разметкі HTML. Кожны мікрафрантальны інтэрфейс мае магчымасць змяняць і паказваць сваю разметку асобна ад астатняй часткі старонкі.
Вэб-кампаненты, напрыклад, дазваляюць ажыццявіць гэты тып будаўніцтва.
План складаецца ў тым, каб ператварыць кожны фрагмент у вэб-кампанент, які можа быць незалежна ўсталяваны ў выглядзе файла a.js, пасля чаго прыкладанні змогуць загружаць і візуалізаваць іх у месцах, прызначаных для іх у макеце тэмы.
Вэб-кампаненты залежаць ад HTML і DOM API, якія могуць выкарыстоўваць іншыя інтэрфейсныя фрэймворкі, а таксама ад стандартнага метаду адпраўкі і атрымання даных праз рэквізіты і падзеі.
Кампазіцыя на баку сервера: Пры такім дызайне элементы карыстальніцкага інтэрфейсу аб'ядноўваюцца на серверы, у выніку чаго на бок кліента адпраўляецца цалкам сфарміраваная старонка, што паскарае загрузку.
Зборка часта выконваецца асобнай службай, якая знаходзіцца паміж вэб-браўзерам і вэб-серверамі. CDN - гэта адзін асобнік сэрвісу (сеткі дастаўкі кантэнту).
Вы можаце выбраць адзін або камбінацыю з двух, у залежнасці ад вашых патрэбаў.
Шаблоны мікрафрантальнай сувязі
Архітэктура мікрафрантальнага інтэрфейсу працуе лепш за ўсё, калі практычна няма ўзаемадзеяння паміж рознымі кампанентамі. Мікрафрэндам часам трэба размаўляць адзін з адным і абменьвацца інфармацыяй. Вось некалькі патэнцыйных мадэляў, якія могуць прывесці да гэтага.
- Вэб-работнікі: Інтэрнэт-працаўнік - гэта механізм, які дазваляе вэб-кантэнту запускаць JavaScript у фонавым рэжыме, незалежна ад іншых скрыптоў, і без уплыву на хуткасць старонкі. Для кожнага мікрапрыкладання будзе прадастаўлены унікальны рабочы API. Гэтая перавага заключаецца ў тым, што працаёмкая праца можа быць выканана ў іншым патоку, што дазваляе патоку карыстацкага інтэрфейсу працягвацца без запаволення або прыпынку.
- Выпраменьвальнік падзей: У гэтым выпадку многія кампаненты ўзаемадзейнічаюць адзін з адным, праслухоўваючы і дзейнічаючы на любыя змены стану ў кампанентах, на якія яны падпісаны. Іншыя мікраінтэрфейсы, якія падпісаліся на гэтую канкрэтную падзею, адказваюць, калі мікраінтэрфейс запускае гэтую падзею. Выпраменьвальнік падзей, які быў уведзены ў кожную мікрапраграму, робіць гэта магчымым.
- Зваротныя выклікі і рэквізіт: У гэтым раздзеле вы вызначаеце бацькоўскі кампанент і даччыныя кампаненты. Камунікацыя арганізавана ў выглядзе дрэвападобнай структуры. Бацькоўскія кампаненты выкарыстоўваюць рэквізіты для перадачы дадзеных у выглядзе функцый уніз па дрэве кампанентаў да даччыных кампанентаў. У сваю чаргу, дзіця можа эфектыўна папярэджваць бацькоў, калі што-небудзь адбываецца ў іх стане, адказваючы на зваротныя выклікі. React выкарыстоўвае гэты рэжым.
Плюсы інтэрфейсу Micro
Развіццё ў хутка аўтаномных камандах
Незалежная каманда можа стварыць кожную частку вэб-праграмы або вэб-сайта пры выкарыстанні метаду мікрафрантальнага інтэрфейсу.
Кожная каманда цалкам аўтаномная, што азначае, што яна адказвае за ўвесь цыкл распрацоўкі кампанентаў, ад канцэпцыі да выпуску і постпрадакшн.
Акрамя таго, гэта азначае, што розныя каманды могуць бесперашкодна супрацоўнічаць, адначасова працуючы над адным праектам.
Такім чынам, цыклы выпуску значна хутчэйшыя, чым гэта было б з пачатковымі маналітамі.
Меншыя кодавыя базы асобных мікрафрантальных праграм прыводзяць да больш чыстага кода
Маналітныя інтэрфейсы маюць вялікія, грувасткія кодавыя базы, якія з часам становяцца ўсё больш хаатычнымі і цяжкімі ў кіраванні.
Мікраінтэрфейсы вырашаюць гэтую праблему. Зыходны код кожнага мікрафрантальнага інтэрфейсу больш зручны, паколькі ён меншы, больш просты і кампактны.
Як следства, агульнае вэб-рашэнне выйграе ад больш чыстага кода.
Палепшаная стабільнасць праграмы з-за слабай сувязі
Вэб-рашэнне рэдка можна падзяліць на цалкам незалежныя часткі. Такім чынам, мікра інтэрфейсы размаўляюць адзін з адным.
Тым не менш, кожная сувязь паміж кампанентамі важная, нягледзячы на няшчыльную сувязь.
Збой аднаго кампанента практычна не ўплывае на працу ўсіх астатніх кампанентаў, што забяспечвае павышаную стабільнасць вэб-рашэння.
Тэставанне асобных функцый стала прасцей
Гэта перавага з'яўляецца вынікам характарыстык мікра інтэрфейсаў. Грунтуючыся на гэтай архітэктурнай канструкцыі, кліенцкі бок вэб-рашэння з'яўляецца модульным, і кожны модуль з'яўляецца аўтаномным.
У выніку камандзе прасцей зрабіць ацэнку невялікай часткі карыстальніцкага інтэрфейсу, чым тэставанне масіўнага маналіту.
Паменшаны памер пакета прыводзіць да больш хуткай загрузкі старонкі
Адной з асноўных прычын затрымкі часу загрузкі ў шматфункцыянальных маналітных вэб-сістэмах з'яўляецца памер пакета JavaScript. З іншага боку, мікрафрантальны падыход палягчае скарачэнне часу загрузкі старонкі.
Браўзеру не трэба шматкроць загружаць непатрэбны код, паколькі вэб-старонка складаецца з некалькіх маленькіх пакетаў. У выніку прадукцыйнасць старонкі і час загрузкі павялічваюцца.
Тэхналагічная незалежнасць
множны інтэрфейсныя рамкі могуць выкарыстоўвацца распрацоўшчыкамі для стварэння адзінага інтэрнэт-рашэння з архітэктурай мікрафрантальнага інтэрфейсу.
Паколькі кожны кампанент аўтаномны, ён можа быць створаны з выкарыстаннем той тэхналогіі, якая лепш за ўсё адпавядае задачам каманды.
Натуральна, праграмістам варта быць асцярожнымі пры выбары фрэймворкаў для праграмнага праекта, за які яны адказваюць, і кансультацыі з іншымі камандамі па-ранейшаму настойліва рэкамендуюцца.
Аднак верагоднасць таго, што вы будзеце вымушаныя выкарыстоўваць састарэлую структуру на працягу ўсяго тэрміну службы праграмы, роўная нулю.
Мінусы Micro Frontend
Тэставанне комплекснага вэб-рашэння цалкам
Тэставанне розных модуляў вэб-рашэння лёгка, калі яно выкарыстоўвае архітэктуру мікрафрантальнага інтэрфейсу. Аднак гэта адрозніваецца ад ацэнкі вэб-праграмы ў цэлым.
Перш чым працягнуць, пераканайцеся, што ўсе дэталі працуюць належным чынам. Гэта можа быць складана, паколькі мікраінтэрфейсы працуюць незалежна і маюць асобныя працэсы дастаўкі.
Дарагія першапачатковыя ўкладанні
Мікрафрантавыя распрацоўкі звычайна патрабуюць значных фінансавых выдаткаў. Сабраць і падтрымліваць шмат інтэрфейсных каманд дорага.
Акрамя таго, вам спатрэбіцца кіруючы персанал, каб арганізаваць працу, пераканацца, што ўсё скаардынавана, і гарантаваць выдатную камунікацыю ў камандзе.
Складанасць распрацоўкі і разгортвання
Працэдуры распрацоўкі і разгортвання могуць стаць больш складанымі ў выніку дызайну мікраінтэрфейсу.
Рашэнне можа быць загрувашчана занадта вялікай колькасцю кампанентаў незалежнымі групамі распрацоўшчыкаў, якія працуюць над адным праектам, напрыклад, што можа выклікаць праблемы на этапе разгортвання.
Правільная зборка ўсіх модуляў і іх плаўнае інтэграванне ў агульную схему таксама не заўсёды простая; гэтая праца звычайна патрабуе поўнага разумення ўсіх залежнасцей.
Праблемы з падтрыманнем узгодненасці карыстальніцкага досведу
Падтрыманне ўзгодненага карыстальніцкага інтэрфейсу складана, калі каманды працуюць асобна над некалькімі часткамі праграмнага забеспячэння.
Вэб-рашэнне павінна быць агульным для ўсіх распрацоўшчыкаў праекта. У адваротным выпадку на дарозе можа быць шмат супярэчнасцяў.
заключэнне
Microfrontends, сучасны архітэктурны дызайн, могуць значна павысіць прадукцыйнасць буйнамаштабных праектаў вэб-распрацоўкі на аснове мікрасэрвісаў.
Гэта дазваляе праграмістам падзяліць поўнае рашэнне на асобныя часткі, якія могуць быць створаны некалькімі аўтаномнымі камандамі. З гэтага вынікаюць шматлікія перавагі, у тым ліку больш хуткае разгортванне функцый, прасцейшае тэсціраванне асобных модуляў і больш плаўнае абнаўленне.
Але ёсць некаторыя цяжкасці і з мікраінтэрфейсамі.
Комплекснае тэсціраванне прыкладання, напрыклад, можа быць складанай задачай.
Акрамя таго, паколькі патрабуецца вялікая каманда інжынераў і адміністратараў, мікрапраекты вельмі дарагія.
Такім чынам, перш чым прыняць рашэнне, вы павінны прыняць да ўвагі ўсе складнікі вашага бізнес-абгрунтавання.
Уладзімір Чамай
Чамусьці я не зразумеў, па якім прынцыпе працуе сувязь паміж асобнымі кампанентамі на франтэндзе. Я не разумею, як вы хочаце злучыць кампаненты, створаныя ў розных рамках. У артыкуле пра гэта нічога няма. Сістэма мерапрыемстваў і слухачоў мне здаецца пеклам на зямлі. Як мы павінны гэта ўявіць?