Съдържание[Крия][Покажи]
- Въведение в micro front-end архитектурата
Плюсове на Micro frontend +-
- Развитие в бързо автономни екипи
- По-малките кодови бази на отделните микро интерфейси водят до по-чист код
- Подобрена стабилност на приложението поради хлабаво свързване
- Тестването на отделни функции е опростено
- Намаленият размер на пакета води до по-бързо зареждане на страницата
- Технологична независимост
- Заключение
Идеята за микроуслуги напоследък привлече много внимание и много фирми я използват, за да премахнат големите, монолитни бекендове.
Преминаването по същия път с интерфейса все още е предизвикателство за много фирми, дори ако този разпределен начин на конструиране на сървърната страна на уеб приложенията е повече или по-малко надежден по отношение на проучване и изпълнение.
Поради тясната си зависимост, монолитът от страна на клиента обикновено затруднява интегрирането на нови функции, приемането на нови технологии и мащабирането на отделни компоненти.
Тези и други предизвикателства подтикнаха фронтенд разработчиците да проучат използването на микроуслуги.
В резултат на това беше разработена чисто нова архитектурна стратегия, известна като микро интерфейс за създаване на предния слой на уебсайтове и уеб базирани приложения.
Терминът беше използван за първи път през 2016 г. и оттогава привлече много внимание за добра кауза.
Тази статия ще даде общо разбиране за това какво представляват микро интерфейсите и проблемите, които адресират. работи, както и плюсове и минуси.
Въведение в micro front-end архитектурата
Съвременен метод за разработка на предния край, наречен микро-предна архитектура, разделя a уеб приложение на малки, независими части.
За крайния потребител тези части изглеждат като едно цяло, дори ако са били конструирани независимо и след това сглобени.
С тази разлика, че микро интерфейсите се отнасят към клиентската, а не към сървърната страна на онлайн решенията, обосновката, която е в основата им, е идентична с тази на микроуслугите.
Създаването на сложни уеб-базирани продукти има най-голям смисъл, когато се използва подход на микро интерфейс.
Микро фронтендите, за разлика от по-конвенционалния монолит на предния край, позволяват на много екипи да си сътрудничат отделно по различни софтуерни проекти.
Програмистите могат да създават уеб приложения по-бързо и с по-голяма мащабируемост и поддръжка, използвайки този архитектурен дизайн.
Казано по-просто, всеки микро интерфейс е просто част от кода за отделен компонент на уеб страницата.
Тези функции се контролират от отделни екипи, всеки от които е специализиран в определена индустрия или цел.
Монолитна срещу микроуслуги срещу микро фронтенд архитектура
Помислете за преместване. Ще бъде ли по-лесно за вас да организирате всичко в множество малки, експертно етикетирани кутии и да преместите всяка поотделно или да опаковате целия персонал в една огромна кутия и да я транспортирате на ново място?
Очевидното решение е налице.
Тази аналогия сравнява двете отделни архитектури на уеб приложения, монолити и микроуслуги (известни също като микро интерфейси).
Монолитна архитектура
Може да успеете да си припомните „добрите стари времена“, когато цялостно приложение беше създадено като единно, сплотено цяло. Такъв метод се нарича монолит, което е стар термин за голям каменен блок.
Това има смисъл.
Монолитните системи имат взаимозависими елементи. Следователно, ако искате да промените нещо или да добавите нова функция, е възможно цялата система да се повреди.
Въпреки че е остаряла, понякога все още съществува. Да, знаем за сегашното ви изражение.
Концептуалното разделяне на кодовата база на два различни компонента — frontend (от страна на клиента) и backend (от страна на сървъра) — стана неизбежно с развитието на новите технологии и софтуерните продукти се усложниха.
Най-популярният метод на работа сега е разделянето на проблемите между презентационния слой, с който взаимодейства крайният потребител, и всичко, което се случва във фонов режим.
Необходими са два екипа за софтуерно инженерство, като предният екип изгражда визуалните компоненти, а задният екип изгражда уеб услугите, бизнес логиката, достъпа до данни, интеграциите и т.н.
Но въпреки това разделение, тази стратегия все още остава монолитна по природа.
Основната промяна е, че сега имаме два големи блока код – фронтенд и бекенд – вместо едно огромно приложение. Монолитните архитектури не трябва да са ужасни; те имат няколко предимства, включително
- Проста и бърза разработка за малки приложения с единична кодова база и много прост дизайн;
- Тестването и отстраняването на грешки са много лесни, защото целият код е на едно място, което улеснява екипа да проследява потока на заявката и да идентифицира грешки;
- В началото на разработването на приложение разходите са по-евтини, тъй като не се правят нито разходи за инфраструктура, нито разходи за разработка, докато не се добавят нови функции.
Недостатъците на тази стратегия са отразени в
- Ограничена гъвкавост при внедряване – екипите трябва да изчакат, ако има само шепа от тях, работещи по проекта, и се изисква ново внедряване всеки път, когато актуализирате кода;
- Възприемането на нови технологии е предизвикателство, тъй като това изисква пренаписване на значителна част, ако не и на целия проект.
- Когато броят на разработчиците се увеличи, системата от код става тясно свързана, сложна и трудна за управление и разбиране.
- Организационни въпроси – всеки член на екипа трябва да използва една и съща версия на библиотеки и да докладва всички промени, ако много екипи работят върху монолитен проект.
- Притеснения относно скалируемостта – тъй като компонентите на проекта са взаимосвързани, отделното им мащабиране създава трудности, които водят до значителни прекъсвания и по-високи разходи.
- Сложната логика на проекта може да бъде трудна за разбиране от новите членове на екипа, особено ако инженерите, които първоначално са работили по него, вече не са на работа.
Развитието на микроуслугите и техните близки роднини, както и микро интерфейсите, обърнаха внимание на основните проблеми с монолитните системи.
Архитектура на микросервизи
Архитектурният метод, известен като микроуслуги, позволява създаването на много слабо свързани и независимо внедряеми по-малки компоненти или услуги, които съставляват бекенда на приложението.
Всяка услуга има своя собствена кодова база, CI/CD тръбопроводи, DevOps процедури и процеси за тяхното изпълнение.
Можете да видите, че монолитният бекенд екип е разделен на отделни екипи, като погледнете изображението по-горе.
Всеки се фокусира индивидуално върху различен аспект на приложението (като продуктова услуга, услуга за търсене и услуга за плащане).
Комуникацията между услугите се осъществява чрез установени протоколи, известни като API, като олекотения REST API протокол, който използва синхронни модели на заявка-отговор.
Друг вариант е да използвате асинхронна комуникация с помощта на софтуер като Kafka, който предлага комуникационни структури и събития за публикуване/абониране.
Микроуслугите се интегрират с интерфейса чрез бекенд за услугата на интерфейса (BFF) или API Gateway през мрежата. BFF предлага персонализиран API за всеки клиент, докато API Gateways предоставят единична точка за достъп за колекция от микроуслуги.
Но дори и с автономни бекенд компоненти и всички предимства, които предоставят, фронтендът все още е монолит.
Следователно тук са полезни микро интерфейсите.
Архитектура на микро интерфейси
Подобно на микроуслугите, където слабо свързаните компоненти се управляват от няколко екипа, микро интерфейсната архитектура прилага концепцията към браузъра.
Тези потребителски интерфейси на уеб приложения следват тази структура, която се състои от донякъде автономни компоненти.
Екипите също се създават въз основа на нуждите на клиентите или случаите на използване, а не на конкретна експертиза или технология.
Следователно екипите участват в микроуслуги и микро фронтенд проекти.
- вертикално нарязани - тъй като има разработчици на интерфейса, експерти по данни, инженери на бекенд, QA инженери и т.н., работещи по същия проект, те създават своите функции от потребителски интерфейс към бази данни; и
- междуфункционален – всеки член на екипа допринася със своя опит в групата.
Екипите могат също така да изберат технологичния стек, който най-добре отговаря на тяхната конкретна линия на бизнес.
Един екип може да използва React, за да програмира своя фрагмент. Друг екип създава нова версия на Angular. Vue.js е един такъв пример.
Микро интерфейсите се използват във връзка със свързани микроуслуги за справяне с проблеми, които екипите за разработка обикновено имат с монолитите. Стратегията предлага следните предимства.
- Технологична свобода: Frontend инженерите могат да избират алтернативни JavaScript рамки, среди за изпълнение и цели технологични стекове в зависимост от нуждите на компанията. В допълнение към остарялата архитектура може да се приложи нова рамка.
- Възможна е по-голяма степен на гъвкавост, тъй като всеки микро интерфейс е самостоятелен и може да бъде разработен, тестван, разгърнат и надграден отделно. В резултат на това, ако един екип работи върху функция и е направил корекция на грешка, а друг екип трябва да добави своя собствена функция, не е необходимо да чака първият екип да изпълни задачата си.
- Автономни екипи и системи: Всеки продуктов екип и следователно всяка функция може да функционира с малка зависимост от другите, което му позволява да продължи да работи дори когато близките компоненти не са налични.
- Множество, по-малки кодови бази: Всеки от микро интерфейсите ще има своя собствена, по-управляема, по-малка кодова база. По-малко хора ще се фокусират върху конкретен UI компонент, ще опростят прегледите на кода и ще подобрят цялостната организация.
- Лесно мащабиране на приложението: Друго предимство на микро интерфейсите е възможността за мащабиране на всяка функция поотделно. За разлика от монолитите, където цялата програма трябва да се мащабира всеки път, когато се добави нова функция, това прави целия процес по-ефективен по отношение както на време, така и на пари.
Как работи микро интерфейсът?
Както казахме по-рано, екипите са вертикално организирани вътре в архитектурата на микро интерфейса, което означава, че са разделени от знания или цел на домейна и са отговорни от началото до края за конкретен продукт.
Може да има една или две бекенд микроуслуги, както и малък интерфейс. Нека разгледаме по-подробно характеристиките на този визуален елемент, взаимодействията с други компоненти на потребителския интерфейс и включването в началната страница.
Микро интерфейсът може да бъде
- цяла страница (напр. страница с подробности за продукта) или
- секции на страницата, които могат да се използват от други екипи, като заглавки, долни колонтитули и ленти за търсене.
Можете да разделите голям уебсайт на няколко вида страници и да дадете всеки тип на определен персонал, върху който да работи.
Няколко компонента обаче често се срещат на множество страници, като горни колонтитули, долни колонтитули, блокове с предложения и т.н. Блок с предложения, например, може да бъде включен в начална страница, страница с подробности за продукта или дори страницата за плащане.
По същество екипите могат да създават части, които други екипи могат да използват на своите страници.
Микро интерфейсите обаче могат да бъдат разгърнати отделно като различни проекти, за разлика от компонентите за многократна употреба.
Всичко това звучи фантастично, но за да се създаде единен интерфейс, страниците и фрагментите трябва по някакъв начин да се комбинират.
Това изисква интеграция на интерфейса, която може да бъде постигната чрез различни стратегии, включително маршрутизиране, композиция и комуникация (вижте графиката по-горе).
Routing
Когато се изисква услуга от страница, контролирана от един екип, за достъп до страница, притежавана от друг екип, маршрутизирането е полезно за интеграция на ниво страница.
Всеки микро интерфейс се обработва като приложение от една страница. Могат да се използват прости HTML връзки за осигуряване на маршрутизиране.
Потребителят може да принуди браузъра да изтегли целевата маркировка от сървър и да замени текущата страница с нова, като щракне върху хипервръзки.
Обвивката на приложението е минимумът от HTML, CSS и JavaScript, който захранва потребителския интерфейс. Дори ако данните за съдържанието, поискани от сървъра, все още чакат, потребителят получава статична показана страница веднага. Централната обвивка на приложението служи като родителско приложение за едностраничните приложения, създадени от различните екипи.
Без значение библиотеката или рамката, която се използва, мета-рамките позволяват сливането на различни страници в една.
композиция
Композицията е процесът на подреждане на частите, за да се поберат в подходящите пространства на страницата. В повечето случаи екипът, който внедрява страницата, не извлича веднага съдържанието на фрагмента.
Вместо това поставя контейнер или маркер там, където фрагментът трябва да бъде в маркирането.
С помощта на различен процес на композиране се извършва окончателното сглобяване. Композицията може да бъде разделена на две основни категории: клиентска и сървърна.
Композиция от страна на клиента: Уеб браузърът се използва за създаване и редактиране на HTML маркиране. Всеки микро интерфейс има способността да променя и показва своето маркиране отделно от останалата част от страницата.
Уеб компонентите, например, ви позволяват да извършите този тип конструкция.
Планът е всеки фрагмент да се превърне в уеб компонент, който може да бъде независимо инсталиран като a.js файл, след което приложенията да могат да ги зареждат и изобразяват в пространствата, определени за тях в оформлението на темата.
Уеб компонентите зависят от HTML и DOM API, които други фронтенд рамки могат да използват, както и стандартен метод за изпращане и получаване на данни чрез подпори и събития.
Композиция от страна на сървъра: С този дизайн елементите на потребителския интерфейс се комбинират на сървъра, което води до изпращане на напълно оформена страница към страната на клиента, което ускорява зареждането.
Сглобяването често се извършва от отделна услуга, която се намира между уеб браузъра и уеб сървърите. CDN е един екземпляр на услугата (мрежа за доставка на съдържание).
Можете да изберете едно или комбинация от двете, в зависимост от вашите нужди.
Комуникационни модели на микро интерфейс
Архитектурата на микро-frontend работи най-добре, когато има малко или никакво взаимодействие между различните компоненти. Микро интерфейсите понякога трябва да говорят помежду си и да споделят информация. Ето няколко потенциални модела, които могат да доведат до това.
- Уеб работници: Онлайн работникът е механизъм, който позволява на уеб съдържанието да изпълнява JavaScript във фонов режим, независимо от други скриптове, и без да оказва влияние върху скоростта на страницата. За всяко микро приложение ще бъде предоставен уникален работен API. Това предимство е, че трудоемката работа може да се извърши в различна нишка, което позволява на нишката на потребителския интерфейс да продължи, без да бъде забавяна или спирана.
- Излъчвател на събития: В този случай много компоненти комуникират помежду си, като слушат и действат спрямо всички промени в състоянието на компонентите, за които са абонирани. Други микро интерфейси, които са се абонирали за това конкретно събитие, отговарят, когато микро интерфейс задейства това събитие. Излъчвател на събития, който е въведен във всеки микро-интерфейс, прави това възможно.
- Обратни повиквания и подпори: В този раздел дефинирате родителски компонент и дъщерни компоненти. Комуникацията е организирана в дървовидна структура. Родителските компоненти използват подпори, за да предадат данните като функции надолу по дървото на компонентите към дъщерните компоненти. На свой ред, детето може ефективно да предупреди родителя, когато нещо се случи в неговото състояние, като отговори на обратни повиквания. React използва този режим.
Плюсове на Micro frontend
Развитие в бързо автономни екипи
Независим екип може да създаде всяка част от уеб приложение или уебсайт, когато използва метод на микро интерфейс.
Всеки екип е напълно автономен, което означава, че отговаря за целия цикъл на разработване на компоненти, от концепцията до пускането и постпродукцията.
Освен това това означава, че различни екипи могат да си сътрудничат безпроблемно, докато едновременно работят по един и същи проект.
Следователно циклите на освобождаване са значително по-бързи, отколкото биха били с предни монолити.
По-малките кодови бази на отделните микро интерфейси водят до по-чист код
Монолитните предни части имат големи, тромави кодови бази, които стават все по-хаотични и трудни за управление с течение на времето.
Микро интерфейсите се справят с този проблем. Изходният код на всеки микро интерфейс е по-управляем, тъй като е по-малък, по-опростен и по-компактен.
Цялостното уеб решение се възползва от по-чист код като следствие.
Подобрена стабилност на приложението поради хлабаво свързване
Едно уеб решение рядко може да бъде разделено на напълно независими части. Следователно микро интерфейсите наистина говорят помежду си.
Всяка връзка между компонентите обаче е значима въпреки разхлабената свързаност.
Повредата на един компонент има малък или никакъв ефект върху работата на всички останали компоненти, което осигурява подобрената стабилност на уеб решението.
Тестването на отделни функции е опростено
Това предимство е резултат от характеристиките на микро интерфейсите. Въз основа на този архитектурен дизайн клиентската страна на уеб решението е модулна и всеки модул е автономен.
В резултат на това оценката на малка част от потребителския интерфейс сама по себе си е по-лесна за екипа, отколкото тестването на масивен монолит.
Намаленият размер на пакета води до по-бързо зареждане на страницата
Една от основните причини за забавено време на зареждане в богати на функции монолитни уеб системи е размерът на JavaScript пакета. От друга страна, подходът на микро интерфейса улеснява намаляването на времето за зареждане на страницата.
Браузърът не трябва да изтегля ненужен код многократно, тъй като една уеб страница е съставена от няколко малки пакета. В резултат на това производителността на страницата и времето за зареждане се увеличават.
Технологична независимост
Многократни предни рамки може да се използва от разработчиците за създаване на едно онлайн решение с микро-frontend архитектура.
Тъй като всеки компонент е автономен, той може да бъде конструиран с помощта на технологията, която отговаря най-добре на задачите на екипа.
Естествено, програмистите трябва да внимават, когато избират рамки за софтуерния проект, за който отговарят, и консултациите с други екипи все още са силно препоръчителни.
Има обаче нулев шанс да бъдете принудени да използвате наследена рамка за продължителността на живота на приложението.
Минуси на Micro Frontend
Цялостно тестване на комплексно уеб решение
Тестването на различни модули на уеб решение е лесно, когато то използва микро-frontend архитектура. Все пак се различава от оценката на уеб приложение като цяло.
Уверете се, че всички части функционират по предназначение, преди да продължите. Това може да е трудно, тъй като микро интерфейсите работят независимо и имат отделни процеси на доставка.
Скъпи първоначални инвестиции
Микро фронтенд разработките обикновено изискват значителни финансови разходи. Скъпо е да се съберат и поддържат много предни екипи.
Освен това ще ви трябва управленски персонал, който да организира работата, да се увери, че всичко е координирано и да гарантира отлична екипна комуникация.
Сложността на разработката и внедряването
Процедурите за разработка и внедряване могат да станат по-сложни в резултат на дизайна на микро-интерфейса.
Решението може да бъде затрупано с твърде много компоненти от независими екипи за разработка, работещи по един и същ проект, например, което може да причини проблеми на етапа на внедряване.
Правилното сглобяване на всички модули и плавното им интегриране в общата схема също не винаги е просто; тази работа обикновено изисква задълбочено разбиране на всички зависимости.
Проблеми с поддържането на съгласуваност в потребителското изживяване
Поддържането на последователен потребителски интерфейс е предизвикателство, когато екипите работят отделно върху няколко части на софтуера.
Уеб решението трябва да се споделя от всички разработчици на проекта. В противен случай може да има много противоречия по пътя.
Заключение
Микро интерфейсите, съвременен архитектурен дизайн, могат значително да подобрят производителността на широкомащабни проекти за уеб разработка, базирани на микроуслуги.
Той позволява на програмистите да разделят цялостното решение на отделни части, които могат да бъдат създадени от няколко автономни екипа. От това произтичат множество предимства, включително по-бързо внедряване на функции, по-лесно тестване на отделни модули и по-безпроблемни надстройки.
Но има и някои трудности с микро интерфейсите.
Цялостното тестване на приложение, например, може да бъде предизвикателство.
Освен това, тъй като е необходим голям екип от инженери и администратори, микро фронтенд проектите са много скъпи.
Следователно, преди да вземете решение, трябва да вземете предвид всички компоненти на вашия бизнес случай.
Владимир Чамай
Някак си не разбрах на какъв принцип работи комуникацията между отделните компоненти на фронтенда. Не разбирам как искате да свържете компоненти, които са създадени в различни рамки. В статията няма нищо за това. Системата от събития и слушатели ми изглежда като ад на земята. Как да си го представим?