Содржина[Крие][Прикажи]
- Вовед во микро предната архитектура
Добрите страни на Micro frontend +-
- Развој во брзо автономни тимови
- Помалите бази на кодови на индивидуални микро фронтови водат до почист код
- Подобрена стабилност на апликацијата поради лабава спојка
- Тестирањето на индивидуалните карактеристики е поедноставно
- Намалената големина на пакетот води до побрзо вчитување на страницата
- Технолошка независност
- Заклучок
Идејата за микроуслуги неодамна привлече големо внимание, а многу фирми ја користат за да ги отстранат големите, монолитни позадини.
Одењето по истиот пат со предниот дел е сè уште предизвик за многу бизниси, дури и ако овој дистрибуиран начин на конструирање на серверската страна на веб-апликациите е повеќе или помалку сигурен во однос на истражување и извршување.
Поради неговата тесна зависност, монолитот од страна на клиентот обично го отежнува интегрирањето на новите функции, прифаќањето нови технологии и размерувањето на поединечните компоненти.
Овие и други предизвици ги поттикнаа програмерите на frontend да истражуваат користејќи микросервис.
Како резултат на тоа, беше развиена сосема нова архитектонска стратегија позната како микро преден дел за создавање на предниот слој на веб-локации и веб-базирани апликации.
Терминот првпат беше употребен во 2016 година и оттогаш привлече големо внимание од добра причина.
Оваа статија ќе даде општо разбирање за тоа што се микро фронтендите и прашањата што ги решаваат. работи, како и добрите и лошите страни.
Вовед во микро предната архитектура
Современиот метод на развој на предниот дел наречен микро-фронтен архитектура го дели a веб апликација на мали, независни делови.
За крајниот корисник, овие делови изгледаат како една единица, дури и ако се направени независно, а потоа составени.
Со таа разлика што микро предните делови се однесуваат на страната на клиентот, а не на страната на серверот, на онлајн решенијата, образложението што лежи во нив е идентично со она на микросервисите.
Изработката на софистицирани веб-базирани производи има најголема смисла кога се користи пристапот на микро предниот дел.
Микро предните делови, за разлика од поконвенционалните предни монолит, им овозможуваат на многу тимови да соработуваат одделно на различни софтверски проекти.
Програмерите можат да креираат веб-апликации побрзо и со поголема приспособливост и одржливост користејќи го овој архитектонски дизајн.
Едноставно кажано, секој микро преден дел е само парче код за посебна компонента на веб-страницата.
Овие карактеристики се контролирани од посебни тимови, од кои секој е специјализиран за одредена индустрија или цел.
Архитектура на монолитна наспроти микросервис и на микро фронтанд архитектура
Размислете за преселување. Дали ќе ви биде поедноставно да организирате сè во неколку мали кутии со стручно етикетирање и да ја преместите секоја поединечно или да го спакувате целиот персонал во една огромна кутија и да ја пренесете на нова локација?
Очигледното решение е таму.
Оваа аналогија ги споредува двете различни архитектури на веб-апликации, монолити и микроуслуги (исто така познати како микро предни делови).
Монолитна архитектура
Можеби ќе можете да се потсетите на „старите добри времиња“ кога беше креирана целосна апликација како единствен, кохезивен ентитет. Таков метод се нарекува монолит, што е стар термин за голем камен блок.
Ова има смисла.
Монолитните системи имаат меѓусебно зависни елементи. Затоа, ако сакате да измените нешто или да додадете нова функција, можно е целиот систем да се расипе.
Иако е застарен, повремено сè уште постои. Да, свесни сме за вашиот моментален израз.
Концептуалната поделба на базата на кодови на две различни компоненти - предниот дел (страна на клиентот) и задниот дел (страна на серверот) - стана неизбежна како што се развиваа новите технологии и софтверските производи станаа покомплицирани.
Најпопуларниот метод на работа сега е поделбата на грижите помеѓу слојот за презентација со кој комуницира крајниот корисник и сè што се случува во позадина.
Потребни се два тима за софтверско инженерство, со предниот тим кој ги гради визуелните компоненти и задниот тим кој ги гради веб-услугите, деловната логика, пристапот до податоци, интеграциите итн.
Сепак, и покрај оваа поделба, оваа стратегија сè уште останува монолитна по природа.
Главната промена е што сега имаме два значителни блока на код - предниот дел и задниот дел - наместо една огромна апликација. Монолитните архитектури не мора да бидат страшни; тие имаат неколку придобивки, вклучувајќи
- Едноставен и брз развој за мали апликации со единствена база на изворни кодови и многу едноставен дизајн;
- Тестирањето и дебагирањето се многу едноставни бидејќи целиот код е на една локација, што му олеснува на тимот да го следи текот на барањето и да ги идентификува грешките;
- На почетокот на развојот на апликацијата, трошоците се поевтини бидејќи не се прават ниту инфраструктурни трошоци ниту трошоци за развој додека не се додадат нови функции.
Недостатоците на оваа стратегија се рефлектираат во
- Ограничена флексибилност при распоредување - тимовите мора да чекаат ако има само неколку од нив кои работат на проектот и потребно е ново распоредување секогаш кога ќе го ажурирате кодот;
- Усвојувањето на нови технологии е предизвик бидејќи тоа бара препишување на значителен дел, ако не и на целиот проект.
- Кога бројот на програмери се зголемува, системот на код станува тесно поврзан, комплициран и тежок за управување и разбирање.
- Организациски прашања – секој член на тимот мора да ја користи истата верзија на библиотеките и да пријави какви било промени доколку многу тимови работат на монолитен проект.
- Загриженост за приспособливост – бидејќи компонентите на проектот се меѓусебно поврзани, нивното размерување одделно претставува потешкотии што резултираат со значителен прекин и повисоки трошоци.
- Сложената логика на проектот би можела да биде тешко разбирлива за новите членови на тимот, особено ако инженерите кои првично работеле на него повеќе не се вработени.
Развојот на микросервисите и нивните блиски роднини, и микро фронтендите, ги решија примарните проблеми со монолитни системи.
Архитектура на микросервис
Архитектонскиот метод познат како микросервиси овозможува создавање на многу лабаво поврзани и независно распоредливи помали компоненти или услуги, кои го сочинуваат задниот дел на апликацијата.
Секоја услуга има своја база на кодови, CI/CD цевки, DevOps процедури и процеси за нивно извршување.
Можете да видите дека монолитниот заден тим е поделен на посебни тимови гледајќи ја сликата погоре.
Секој се фокусира поединечно на различен аспект од апликацијата (како што се услугата за производи, услугата за пребарување и услугата за плаќање).
Комуникацијата помеѓу услугите се јавува преку воспоставени протоколи познати како API, како што е лесниот протокол REST API кој користи синхрони обрасци за барање-одговор.
Друга опција е да се користи асинхрона комуникација користејќи софтвер како Кафка, кој нуди објава/претплати комуникациски структури и настани.
Микроуслугите се интегрираат со предниот дел преку заден дел за услугата преден дел (BFF) или API Gateway преку мрежата. BFF нуди прилагодено API за секој клиент, додека API Gateways даваат единствена точка на пристап за колекција на микросервис.
Но, дури и со автономните задни компоненти и сите предности што ги обезбедуваат, предниот дел е сè уште монолит.
Затоа, тука се корисни микро предните делови.
Архитектура на микро предни делови
Слично на микросервисите, каде што слабо поврзаните компоненти се управувани од неколку тимови, архитектурата на микро предниот дел го применува концептот на прелистувачот.
Овие кориснички интерфејси на веб-апликации ја следат оваа структура, која се состои од донекаде автономни компоненти.
Тимовите, исто така, се создаваат според потребите на клиентите или случаите на употреба наместо конкретна експертиза или технологија.
Следствено, тимовите се вклучени во проекти за микросервис и микро фронтенд.
- вертикално исечени - бидејќи има програмери на предниот дел, експерти за податоци, инженери за заднина, инженери за QA итн. кои исто така работат на истиот проект, тие ги создаваат своите карактеристики од кориснички интерфејс до бази на податоци; и
- крос-функционални - секој член на тимот придонесува со својата експертиза во групата.
Тимовите исто така можат да го изберат технолошкиот куп што најмногу одговара на нивната конкретна дејност.
Еден тим може да користи React за да го програмира својот фрагмент. Друг тим создава нова Angular верзија. Vue.js е еден таков пример.
Микро предните делови се користат заедно со поврзаните микроуслуги за да се решат проблемите што тимовите за развој обично ги имаат со монолитите. Стратегијата ги нуди следните предности.
- Технолошка слобода: инженерите на Frontend можат да изберат алтернативни рамки за JavaScript, околини за време на работа и цели технолошки купови во зависност од потребите на компанијата. Покрај застарената архитектура, може да се примени нова рамка.
- Можен е поголем степен на флексибилност бидејќи секој микро преден дел е самостоен и може да се развива, тестира, распоредува и надградува одделно. Како резултат на тоа, ако еден тим работи на функција и извршил поправка на грешки, а друг тим треба да додаде своја карактеристика, тие не треба да чекаат првиот тим да ја заврши својата задача.
- Автономни тимови и системи: секој тим на производ, а со тоа и секоја карактеристика, може да функционира со мала зависност од другите, што му овозможува да продолжи да работи дури и кога блиските компоненти се недостапни.
- Повеќекратни, помали бази на кодови: секој од микро предните делови ќе има своја, поуправлива, помала база на кодови. Помалку луѓе ќе се фокусираат на одредена компонента на корисничкиот интерфејс, ќе ги поедностават прегледите на кодот и ќе ја подобрат целокупната организација.
- Едноставно скалирање на апликации: Друга придобивка од микро предните делови е способноста да се скалира секоја карактеристика поединечно. За разлика од монолитите, каде што целата програма мора да се скалира секој пат кога се додава нова функција, ова го прави целиот процес поефикасен и од аспект на време и пари.
Како функционира микро предниот дел?
Како што претходно наведовме, тимовите се вертикално организирани во архитектурата на микро предниот дел, што значи дека тие се одделени со знаење или цел на доменот и се одговорни од почеток до крај за одреден производ.
Може да има еден или два задни микросервиси, како и мал преден дел. Подетално, да ги испитаме карактеристиките на овој визуелен елемент, интеракциите со другите компоненти на корисничкиот интерфејс и инкорпорирањето во почетната страница.
Микро преден дел може да биде
- цела страница (на пр. страница со детали за производот) или
- делови од страницата што може да ги користат други тимови, како што се заглавија, подножја и ленти за пребарување.
Можете да поделите голема веб-локација на неколку видови страници и секој тип да му го дадете на одреден персонал за работа.
Сепак, неколку компоненти често се појавуваат на бројни страници, како што се заглавија, подножја, блокови со предлози итн. Блок со предлози, на пример, може да се вклучи на почетната страница, страницата со детали за производот, па дури и на страницата за наплата.
Во суштина, тимовите можат да креираат парчиња што другите тимови можат да ги користат на нивните страници.
Сепак, микро предните делови може да се распоредат одделно како различни проекти за разлика од компонентите за повеќекратна употреба.
Сето ова звучи фантастично, но за да се создаде унифициран интерфејс, страниците и фрагментите некако мора да се комбинираат.
Ова бара интеграција на предниот дел, која може да се постигне преку различни стратегии, вклучувајќи рутирање, композиција и комуникација (видете ја графиката погоре).
Рутирање
Кога услугата од страница контролирана од еден тим е потребна за пристап до страница во сопственост на друг тим, рутирањето е корисно за интеграција на ниво на страница.
Секој микро преден дел се постапува како апликација на една страница. Едноставните HTML врски може да се користат за да се обезбеди рутирање.
Корисникот може да го принуди прелистувачот да ја преземе целната ознака од сервер и да ја замени тековната страница со нова со кликнување на хиперврски.
Школката на апликацијата е минималниот минимум HTML, CSS и JavaScript што го напојува интерфејсот. Дури и ако податоците за содржината побарани од серверот сè уште чекаат, корисникот веднаш добива статична прикажана страница. Централната обвивка на апликации служи како матична апликација за апликациите на една страница креирани од различни тимови.
Без разлика на библиотеката или рамката што се користи, мета-рамките овозможуваат спојување на различни страници во една.
составот
Композицијата е процес на распоредување на парчињата за да се вклопат во соодветните простори на страницата. Во повеќето случаи, тимот што ја распоредува страницата не ја презема веднаш содржината на фрагментот.
Наместо тоа, поставува место за место или маркер каде што фрагментот треба да биде во ознаката.
Користејќи различен процес на компонирање, конечното склопување се постигнува. Составот може да се подели во две основни категории: клиентска и серверска страна.
Состав од страна на клиентот: Веб-прелистувачот се користи за креирање и уредување на HTML обележување. Секој микро преден дел има можност да се менува и да го прикаже своето обележување одделно од остатокот од страницата.
Веб-компонентите, на пример, ви дозволуваат да извршите ваков тип на градба.
Планот е секој фрагмент да се претвори во веб-компонента што може независно да се инсталира како датотека a.js, по што апликациите ќе можат да ги вчитаат и прикажуваат во местата одредени за нив во распоредот на темата.
Веб-компонентите зависат од HTML и DOM API, кои можат да ги користат другите рамки на предниот дел, како и од стандардниот метод за испраќање и примање податоци преку реквизити и настани.
Состав од страна на серверот: Со овој дизајн, деловите од корисничкиот интерфејс се комбинираат на серверот, што резултира со целосно формирана страница која се испраќа до клиентската страна, со што се забрзува вчитувањето.
Склопувањето често се врши од посебна услуга која се наоѓа помеѓу веб-прелистувачот и веб-серверите. CDN е еден пример на услугата (мрежа за испорака на содржина).
Можете да изберете еден или комбинација од двете, во зависност од вашите потреби.
Шеми за комуникација со микро преден дел
Архитектурата на микро-фронтенд најдобро функционира кога има мала или никаква интеракција помеѓу различните компоненти. Микро фронтендовите повремено треба да разговараат еден со друг и да споделуваат информации. Еве неколку потенцијални обрасци кои би можеле да доведат до тоа.
- Веб работници: Онлајн работник е механизам што овозможува веб-содржините да работат JavaScript во позадина, независно од другите скрипти и без да влијае на брзината на страницата. За секоја микро апликација ќе биде обезбеден уникатен работник API. Оваа придобивка е што работата одзема многу време може да се направи во друга нишка, овозможувајќи нишката на UI да продолжи без да биде забавена или запрена.
- Емитер на настани: Во овој случај, многу компоненти комуницираат една со друга преку слушање и дејствување на какви било промени на состојбата во компонентите на кои се претплатени. Другите микро преден дел што се претплатиле на тој специфичен настан реагираат кога микрофронтендот го активира тој настан. Емитер на настани што е воведен во секој микрофронт го прави ова изводливо.
- Повратни повици и реквизити: Во овој дел, вие дефинирате матична компонента и детски компоненти. Комуникацијата е организирана во структура слична на дрво. Родителските компоненти користат реквизити за да ги пренесат податоците како функции низ дрвото на компонентите до детските компоненти. За возврат, детето може ефикасно да го предупреди родителот кога нешто се случува во нивната состојба, одговарајќи на повратни повици. React го користи овој режим.
Добрите страни на Micro frontend
Развој во брзо автономни тимови
Независен тим може да го креира секој дел од веб-апликација или веб-локација кога користи метод на микро преден дел.
Секој тим е целосно автономен, што значи дека е задолжен за целиот циклус на развој на компонентите, од зачнувањето до објавувањето и постпродукцијата.
Дополнително, тоа имплицира дека различни тимови можат беспрекорно да соработуваат додека истовремено работат на истиот проект.
Затоа, циклусите на ослободување се значително побрзи отколку што би биле со предните монолити.
Помалите бази на кодови на индивидуални микро фронтови водат до почист код
Монолитните предни краеви имаат големи, непоколебливи бази на кодови кои стануваат сè похаотични и предизвикувачки за управување со текот на времето.
Микро предните делови го решаваат овој проблем. Изворниот код на секој микро преден дел е податлив бидејќи е помал, поедноставен и покомпактен.
Целокупното веб-решение има корист од почист код како последица.
Подобрена стабилност на апликацијата поради лабава спојка
Веб-решение ретко кога може да се подели на целосно независни делови. Следствено, микро фронтендите зборуваат еден со друг.
Сепак, секоја врска помеѓу компонентите е значајна и покрај лабавото поврзување.
Неуспехот на една компонента има мало или никакво влијание врз работата на сите други компоненти, што обезбедува подобрена стабилност на веб-решението.
Тестирањето на индивидуалните карактеристики е поедноставно
Оваа придобивка произлегува од карактеристиките на микро предните делови. Врз основа на овој архитектонски дизајн, клиентската страна на веб-решението е модуларна и секој модул е автономен.
Како резултат на тоа, оценувањето на мал дел од корисничкиот интерфејс сам по себе е полесно за тимот отколку тестирање на огромен монолит.
Намалената големина на пакетот води до побрзо вчитување на страницата
Една од основните причини за одложеното време на вчитување во монолитни веб системи богати со карактеристики е големината на пакетот JavaScript. Од друга страна, пристапот на микро предниот дел го олеснува намалувањето на времето за вчитување на страницата.
Прелистувачот не мора постојано да презема непотребен код бидејќи веб-страницата е составена од неколку мали пакети. Како резултат на тоа, се зголемуваат перформансите на страницата и времето на вчитување.
Технолошка независност
повеќе предни рамки може да се користи од страна на програмерите за да се создаде единствено онлајн решение со микро-фронтен архитектура.
Бидејќи секоја компонента е автономна, може да се конструира со користење на која било технологија најдобро одговара на задачите на тимот.
Секако, програмерите треба да бидат претпазливи при изборот на рамки за софтверскиот проект за кој се задолжени, а консултациите со другите тимови сè уште се препорачуваат.
Сепак, постои нула шанса да бидете принудени да користите стара рамка за времетраењето на животниот век на апликацијата.
Недостатоци на Micro Frontend
Комплексно тестирање на веб решенија во целост
Тестирањето на различните модули на веб-решението е лесно кога користи микро-фронтен архитектура. Сепак, се разликува од оценувањето на веб-апликацијата како целина.
Проверете дали сите делови функционираат како што е предвидено пред да продолжите. Ова може да биде тешко бидејќи микро предните делови работат независно и имаат посебни процеси на испорака.
Скапи почетни инвестиции
Развојот на микро предниот дел обично бара значителни финансиски трошоци. Скапо е да се соберат и одржуваат многу предни тимови.
Дополнително, ќе ви треба менаџерски персонал за да ја организирате работата, да бидете сигурни дека сè е координирано и да гарантирате одлична тимска комуникација.
Комплексноста на развојот и распоредувањето
Процедурите за развој и распоредување може да станат покомплицирани како резултат на дизајнот на микро-фронт.
Решението може да биде преполно со премногу компоненти од независни развојни тимови кои работат на истиот проект, на пример, што може да предизвика проблеми во фазата на распоредување.
Правилното склопување на сите модули и нивната непречена интеграција во целокупната шема исто така не е секогаш едноставна; оваа работа обично бара темелно разбирање на сите зависности.
Проблеми со одржување на кохерентност во корисничкото искуство
Одржувањето конзистентен кориснички интерфејс е предизвик кога тимовите работат одделно на неколку делови од софтверот.
Веб решението треба да биде споделено од сите развивачи на проектот. Во спротивно, може да има многу противречности на патот.
Заклучок
Микро предните делови, современ архитектонски дизајн, можат во голема мера да ги подобрат перформансите на големите проекти за развој на веб базирани на микросервис.
Тоа им овозможува на програмерите да го поделат целосното решение на дискретни делови кои можат да бидат креирани од неколку автономни тимови. Од ова следуваат бројни придобивки, вклучувајќи побрзо пуштање на функции, полесно тестирање на поединечни модули и повеќе беспрекорни надградби.
Но, има некои тешкотии и со микро предните делови.
Сеопфатното тестирање на апликацијата, на пример, може да биде предизвик.
Дополнително, бидејќи е потребен голем тим од инженери и администратори, проектите за микро предниот дел се многу скапи.
Следствено, пред да донесете одлука, мора да ги земете предвид сите компоненти на вашиот деловен случај.
Владимир Чамај
Некако не разбрав на кој принцип функционира комуникацијата помеѓу поединечните компоненти на предниот дел. Не разбирам како сакате да поврзете компоненти што се креирани во различни рамки. Нема ништо во статијата за тоа. Системот на настани и слушатели ми изгледа како пекол на земјата. Како треба да го замислиме?