Преглед садржаја[Сакрити][Прикажи]
Идеја о микроуслугама је недавно привукла велику пажњу и многе компаније је користе да би уклониле велике, монолитне позадине.
Ићи истим путем са фронтендом и даље је изазов за многа предузећа, чак и ако је овај дистрибуирани начин конструисања веб апликација на страни сервера мање-више поуздан у смислу истраживања и извршења.
Због своје блиске зависности, монолит на страни клијента обично отежава интеграцију нових функција, усвајање нових технологија и скалирање појединачних компоненти.
Ови и други изазови су навели фронтенд програмере да истраже коришћење микросервиса.
Као резултат тога, развијена је потпуно нова архитектонска стратегија позната као микро фронтенд за креирање фронт-енд слоја веб локација и веб апликација.
Термин је први пут употребљен 2016. године и од тада привлачи велику пажњу за добар циљ.
Овај чланак ће дати опште разумевање шта су микро фронтендови и проблеме којима се баве. ради, као и за и против.
Увод у микро фронт-енд архитектуру
Савремени метод развоја фронт-енда који се зове микро-фронтенд архитектура дели а веб апликација на мале, независне делове.
За крајњег корисника, ови делови изгледају као једна целина чак и ако су конструисани независно, а затим састављени.
С том разликом што се микро фронтендови односе на клијентску, а не на серверску страну онлајн решења, образложење које лежи у њиховој основи је идентично као код микросервиса.
Прављење софистицираних производа заснованих на вебу има највише смисла када се користи микро приступни приступ.
Микро фронтендови, за разлику од конвенционалнијег фронт-енд монолита, омогућавају многим тимовима да одвојено сарађују на различитим софтверским пројектима.
Програмери могу да креирају веб апликације брже и са већом скалабилношћу и лакоћом одржавања користећи овај архитектонски дизајн.
Да поједноставимо, сваки микро фронтенд је само део кода за посебну компоненту веб странице.
Ове карактеристике контролишу засебни тимови, од којих је сваки специјализован за одређену индустрију или циљ.
Монолитна против микросервиса против микро архитектуре фронтенда
Размислите о пресељењу. Да ли ће вам бити једноставније да све организујете у неколико малих, стручно обележених кутија и преместите сваку појединачно или да спакујете цело особље у једну огромну кутију и превезете је на нову локацију?
Очигледно решење је ту.
Ова аналогија упоређује две различите архитектуре веб апликација, монолите и микросервисе (познате и као микро фронтендови).
Монолитна архитектура
Можда ћете моћи да се сетите „старих добрих дана“ када је комплетна апликација креирана као јединствена, кохезивна целина. Такав метод се назива монолит, што је стари израз за велики камени блок.
Ово има смисла.
Монолитни системи имају међусобно зависне елементе. Стога, ако желите нешто да измените или додате нову функцију, могуће је да се цео систем поквари.
Иако је застарео, повремено још увек постоји. Да, свесни смо вашег тренутног израза.
Концептуална подела кодне базе на две различите компоненте — фронтенд (на страни клијента) и бацкенд (на страни сервера) — постала је неизбежна како су се нове технологије развијале и софтверски производи постајали све компликованији.
Најпопуларнији метод рада је сада раздвајање забринутости између слоја презентације са којим крајњи корисник комуницира и свега што се дешава у позадини.
Потребна су му два тима за софтверско инжењерство, са фронт-енд тимом који гради визуелне компоненте и бацк-енд тимом који гради веб услуге, пословну логику, приступ подацима, интеграције итд.
Међутим, упркос овом раздвајању, ова стратегија и даље остаје монолитна по природи.
Главна промена је да сада имамо два велика блока кода — фронтенд и бацкенд — уместо једне огромне апликације. Монолитне архитектуре не морају бити страшне; имају неколико предности, укључујући
- Једноставан и брз развој за мале апликације са једном изворном кодном базом и веома једноставним дизајном;
- Тестирање и отклањање грешака су веома једноставни јер се сав код налази на једној локацији, што олакшава тиму да прати ток захтева и идентификује грешке;
- У раној фази развоја апликације, трошкови су јефтинији јер ни трошкови инфраструктуре ни трошкови развоја не настају док се не додају нове функције.
Недостаци ове стратегије се огледају у
- Ограничена флексибилност примене – тимови морају да чекају ако само неколицина њих ради на пројекту и нова примена је потребна сваки пут када ажурирате код;
- Усвајање нових технологија је изазовно јер то захтева преписивање значајног дела, ако не и целог пројекта.
- Када се број програмера повећава, систем кода постаје блиско повезан, компликован и тежак за управљање и разумевање.
- Организациони проблеми – сваки члан тима мора да користи исту верзију библиотека и пријави све промене ако многи тимови раде на монолитном пројекту.
- Забринутост око скалабилности – пошто су компоненте пројекта међусобно повезане, њихово одвојено скалирање представља потешкоће које резултирају значајним застојима и већим трошковима.
- Сложена логика пројекта могла би бити тешка за разумевање нових чланова тима, посебно ако инжењери који су првобитно радили на њему више нису запослени.
Развој микросервиса и њихових блиских сродника, као и микро фронтендова, решио је примарне проблеме монолитних система.
Архитектура микросервиса
Архитектонски метод познат као микросервис омогућава креирање многих лабаво повезаних и независно применљивих мањих компоненти или услуга које чине позадину апликације.
Свака услуга има сопствену базу кода, ЦИ/ЦД цевоводе, ДевОпс процедуре и процесе за њихово покретање.
Можете видети да је монолитни бацкенд тим подељен у засебне тимове гледајући слику изнад.
Сваки се посебно фокусира на различите аспекте апликације (као што су услуга производа, услуга претраживања и услуга плаћања).
Комуникација између услуга се одвија преко успостављених протокола познатих као АПИ-ји, као што је лагани РЕСТ АПИ протокол који користи синхроне обрасце захтев-одговор.
Друга опција је коришћење асинхроне комуникације помоћу софтвера као што је Кафка, који нуди комуникацијске структуре и догађаје за објављивање/претплату.
Микроуслуге се интегришу са фронтендом преко позадине за услугу фронтенд (БФФ) или АПИ мрежног пролаза кроз мрежу. БФФ нуди прилагођени АПИ за сваког клијента, док АПИ мрежни пролази дају једну тачку приступа за колекцију микросервиса.
Али чак и са аутономним позадинским компонентама и свим предностима које пружају, фронтенд је и даље монолит.
Због тога су микро фронтендови корисни.
Архитектура микро фронтенда
Слично микросервисима, где лабаво повезаним компонентама управља неколико тимова, микро фронтенд архитектура примењује концепт на претраживач.
Ови кориснички интерфејси веб апликација прате ову структуру, која се састоји од донекле аутономних компоненти.
Тимови се такође креирају према потребама клијената или случајевима коришћења, а не према одређеној стручности или технологији.
Сходно томе, тимови су укључени у микросервисе и микро фронтенд пројекте.
- вертикално исечени — пошто на истом пројекту раде и фронтенд програмери, стручњаци за податке, позадински инжењери, КА инжењери, итд., они креирају своје карактеристике из кориснички интерфејс у базе података; и
- међуфункционални – сваки члан тима доприноси својој стручности групи.
Тимови такође могу да изаберу технолошку групу која најбоље одговара њиховој одређеној линији пословања.
Један тим може да користи Реацт да програмира свој фрагмент. Други тим креира нову Ангулар верзију. Вуе.јс је један такав пример.
Микро фронтендови се користе заједно са сродним микросервисима за решавање проблема које развојни тимови обично имају са монолитима. Стратегија нуди следеће предности.
- Слобода технологије: Фронтенд инжењери могу да изаберу алтернативне ЈаваСцрипт оквире, рунтиме окружења и читав низ технологија у зависности од потреба компаније. Поврх застареле архитектуре, може се применити нови оквир.
- Већи степен флексибилности је могућ пошто је сваки микро фронтенд самосталан и може се засебно развијати, тестирати, имплементирати и надоградити. Као резултат тога, ако један тим ради на функцији и уложио је исправку грешке, а други тим мора да дода сопствену функцију, не морају да чекају да први тим заврши свој задатак.
- Аутономни тимови и системи: Сваки тим производа, а самим тим и свака функција, могу да функционишу уз малу зависност од других, што му омогућава да настави да ради чак и када су оближње компоненте недоступне.
- Вишеструке, мање базе кода: Сваки од микро фронтендова ће имати сопствену, мању кодну базу која је лакша за управљање. Мање људи ће се фокусирати на одређену компоненту корисничког интерфејса, поједноставити преглед кода и побољшати општу организацију.
- Једноставно скалирање апликације: Још једна предност микро фронтендова је могућност скалирања сваке функције појединачно. За разлику од монолита, где се цео програм мора скалирати сваки пут када се дода нова функција, ово чини цео процес ефикаснијим у смислу времена и новца.
Како ради микро фронтенд?
Као што смо раније рекли, тимови су вертикално организовани унутар микро фронтенд архитектуре, што значи да су раздвојени знањем о домену или сврси и одговорни су од почетка до краја за одређени производ.
Може имати једну или две позадинске микроуслуге као и мали фронтенд. Детаљније, хајде да испитамо карактеристике овог визуелног елемента, интеракције са другим компонентама корисничког интерфејса и уградњу у почетну страницу.
Микро фронтенд може бити
- цела страница (нпр. страница са детаљима о производу) или
- делове странице које могу да користе други тимови, као што су заглавља, подножја и траке за претрагу.
Велику веб локацију можете поделити на неколико врста страница и дати сваки тип одређеном особљу на коме ће радити.
Међутим, неколико компоненти се често појављују на бројним страницама, као што су заглавља, подножја, блокови предлога, итд. Блок предлога, на пример, може бити укључен на почетну страницу, страницу са детаљима о производу или чак страницу за плаћање.
У суштини, тимови могу креирати делове које други тимови могу користити на својим страницама.
Микро фронтендови, међутим, могу бити распоређени одвојено као различити пројекти за разлику од компоненти за вишекратну употребу.
Све ово звучи фантастично, али да би се направио јединствен интерфејс, странице и фрагменти морају некако да се комбинују.
Ово захтева интеграцију фронтенда, што се може постићи различитим стратегијама, укључујући рутирање, композицију и комуникацију (погледајте слику изнад).
Роутинг
Када је за приступ страници у власништву другог тима потребна услуга са странице коју контролише један тим, рутирање је корисно за интеграцију на нивоу странице.
Сваки микро фронтенд се обрађује као апликација на једној страници. За рутирање се могу користити једноставне ХТМЛ везе.
Корисник може да натера претраживач да преузме циљну ознаку са сервера и замени тренутну страницу новом кликом на хипервезе.
Схелл апликације је минимум ХТМЛ-а, ЦСС-а и ЈаваСцрипт-а који покреће кориснички интерфејс. Чак и ако подаци о садржају тражени од сервера још увек чекају, корисник одмах добија статичну приказану страницу. Централна љуска апликације служи као надређена апликација за апликације на једној страници које су креирали различити тимови.
Без обзира на библиотеку или оквир који се користи, мета-оквири омогућавају спајање различитих страница у једну.
састав
Композиција је процес распоређивања делова како би се уклопили у одговарајуће просторе на страници. У већини случајева, тим који поставља страницу не преузима одмах садржај фрагмента.
Уместо тога, поставља чувар места или маркер тамо где би фрагмент требало да буде у маркупу.
Користећи другачији процес састављања, завршава се коначна монтажа. Композиција се може поделити у две основне категорије: на страни клијента и на страни сервера.
Састав на страни клијента: Веб претраживач се користи за креирање и уређивање ХТМЛ ознака. Сваки микро фронтенд има могућност да промени и прикаже своје ознаке одвојено од остатка странице.
Веб компоненте, на пример, омогућавају вам да извршите ову врсту конструкције.
План је да се сваки фрагмент претвори у веб компоненту која се може самостално инсталирати као а.јс датотека, након чега апликације могу да их учитавају и рендерују у просторима који су за њих одређени у изгледу теме.
Веб компоненте зависе од ХТМЛ и ДОМ АПИ-ја, које други фронтенд оквири могу да користе, као и од стандардног метода слања и примања података путем реквизита и догађаја.
Композиција на страни сервера: Са овим дизајном, делови корисничког интерфејса се комбинују на серверу, што доводи до тога да се потпуно формирана страница шаље на страну клијента, убрзавајући учитавање.
Монтажу се често обавља посебна услуга која се налази између веб претраживача и веб сервера. ЦДН је једна инстанца услуге (мрежа за испоруку садржаја).
Можете одабрати једну или комбинацију ова два, у зависности од ваших потреба.
Микро фронтенд комуникациони обрасци
Архитектура микро фронтенда најбоље функционише када постоји мала или никаква интеракција између различитих компоненти. Микро фронтендови повремено морају да разговарају једни са другима и деле информације. Ево неколико потенцијалних образаца који би могли довести до тога.
- Веб радници: Радник на мрежи је механизам који омогућава веб садржају да покреће ЈаваСцрипт у позадини, независно од других скрипти, и без утицаја на брзину странице. За сваку микро апликацију биће обезбеђен јединствени раднички АПИ. Ова предност је у томе што се дуготрајни посао може обавити у другој нити, омогућавајући УИ нити да настави без успоравања или заустављања.
- Емитер догађаја: У овом случају, многе компоненте комуницирају једна са другом слушајући и делујући на промене стања у компонентама на које су претплаћене. Други микро фронтендови који су се претплатили на тај одређени догађај одговарају када микро фронтенд покрене тај догађај. Емитер догађаја који је уведен у сваки микро-фронтенд чини ово изводљивим.
- Повратни позиви и реквизити: У овом одељку дефинишете родитељску компоненту и подређене компоненте. Комуникација је организована у структуру налик стаблу. Надређене компоненте користе пропс да пренесу податке као функције низ стабло компоненти до подређених компоненти. Заузврат, дете може ефикасно да упозори родитеља када се било шта догоди у њиховом стању тако што ће одговорити на повратне позиве. Реацт користи овај режим.
Предности микро фронтенда
Развој у брзо аутономним тимовима
Независни тим може да креира сваки део веб апликације или веб локације када користи микро фронтенд метод.
Сваки тим је потпуно аутономан, што значи да је задужен за цео циклус развоја компоненте, од концепције до објављивања и постпродукције.
Поред тога, то имплицира да различити тимови могу неометано да сарађују док истовремено раде на истом пројекту.
Стога су циклуси објављивања знатно бржи него што би били код монолита фронт-енда.
Мање кодне базе појединачних микро фронтендова доводе до чистијег кода
Монолитни предњи крајеви имају велике, гломазне базе кодова које временом постају све хаотичније и изазовније за управљање.
Микро фронтендови решавају овај проблем. Изворни код сваког микро фронтенда је лакши за управљање јер је мањи, једноставнији и компактнији.
Као последица тога, целокупно веб решење има користи од чистијег кода.
Побољшана стабилност апликације због лабавог споја
Веб решење се ретко може поделити на потпуно независне делове. Сходно томе, микро фронтендови разговарају једни са другима.
Међутим, свака веза између компоненти је значајна упркос слабој повезаности.
Квар једне компоненте има мали или никакав утицај на рад свих осталих компоненти, што обезбеђује побољшану стабилност веб решења.
Тестирање појединачних карактеристика је поједностављено
Ова предност произилази из карактеристика микро фронтендова. На основу овог архитектонског дизајна, клијентска страна веб решења је модуларна и сваки модул је аутономан.
Као резултат тога, тиму је лакше проценити само мали део корисничког интерфејса него да тестира масивни монолит.
Смањена величина пакета доводи до бржег учитавања странице
Један од примарних узрока одложеног времена учитавања у монолитним веб системима богатим функцијама је величина ЈаваСцрипт пакета. Са друге стране, приступ микро фронтенду олакшава смањење времена учитавања странице.
Прегледач не мора више пута да преузима непотребан код пошто се веб страница састоји од неколико сићушних пакета. Као резултат тога, повећавају се перформансе странице и време учитавања.
Технолошка независност
вишеструко фронт-енд оквири програмери могу користити за креирање јединственог онлајн решења са микро-фронтенд архитектуром.
Пошто је свака компонента аутономна, може се конструисати коришћењем било које технологије која најбоље одговара задацима тима.
Наравно, програмери би требало да буду опрезни када бирају оквире за софтверски пројекат за који су задужени, а консултације са другим тимовима се и даље саветују.
Међутим, нема шансе да ћете бити приморани да користите застарели оквир током трајања апликације.
Недостаци микро фронтенда
Тестирање комплексног веб решења у целини
Тестирање различитих модула веб решења је лако када се користи микро-фронтенд архитектура. Међутим, разликује се од процене веб апликације у целини.
Проверите да ли сви делови функционишу како је предвиђено пре него што наставите. Ово може бити тешко јер микро фронтендови раде независно и имају одвојене процесе испоруке.
Скупе почетне инвестиције
Развој микро фронтенда обично захтева значајне финансијске издатке. Скупо је саставити и одржавати многе фронт-енд тимове.
Поред тога, биће вам потребно руководеће особље да организује посао, да се увери да је све координисано и да гарантује одличну тимску комуникацију.
Сложеност развоја и примене
Процедуре развоја и примене могу постати компликованије као резултат дизајна микро фронтенда.
Решење би могло бити претрпано превише компоненти од стране независних развојних тимова који раде на истом пројекту, на пример, што би могло да изазове проблеме у фази примене.
Право склапање свих модула и њихова глатка интеграција у целокупну шему такође није увек једноставна; овај рад обично захтева темељно разумевање свих зависности.
Проблеми са одржавањем кохерентности у корисничком искуству
Одржавање доследног корисничког интерфејса је изазов када тимови раде одвојено на неколико делова софтвера.
Веб решење треба да деле сви програмери пројекта. Иначе, на путу може бити много контрадикторности.
Zakljucak
Микро фронтендови, савремени архитектонски дизајн, могу у великој мери побољшати перформансе великих пројеката веб развоја заснованих на микросервисима.
Омогућава програмерима да поделе комплетно решење на дискретне делове које може креирати неколико аутономних тимова. Из овога произилазе бројне предности, укључујући брже увођење функција, лакше тестирање појединачних модула и беспрекорније надоградње.
Али постоје и неке потешкоће са микро фронтендовима.
Свеобухватно тестирање апликације, на пример, може бити изазовно.
Поред тога, пошто је потребан велики тим инжењера и администратора, микро фронтенд пројекти су веома скупи.
Сходно томе, пре него што донесете одлуку, морате узети у обзир све компоненте вашег пословног случаја.
Владимир Чамај
Некако нисам разумео на ком принципу функционише комуникација између појединих компоненти на фронтенду. Не разумем како желите да повежете компоненте које су креиране у различитим оквирима. У чланку нема ништа о томе. Систем догађаја и слушалаца ми личи на пакао на земљи. Како да то замислимо?