Отказ от отговорност: Тази статия е част от серия microfrontend, която включва и по-подробно видео. Можете да го намерите в долната част на тази статия.

Правилното разработване на предния интерфейс е голямо предизвикателство, но мащабирането на разработката на предния интерфейс, така че няколко екипа да могат да работят едновременно върху големи и сложни продукти, е много по-трудно. Ще разгледаме скорошната тенденция за разбиване на фронтенд монолитите на по-малки, по-управляеми модули, която стана все по-често срещана. Тази архитектура подобрява ефективността и ефикасността на екипите, които си сътрудничат върху интерфейсния код. Възможно е вашата цел да е да създадете адаптивно или прогресивно уеб приложение. Но няма сигурно място, където да започнете да интегрирате тези функции в съществуващ код. Вашата цел може също да е да използвате нови функции на езика на JavaScript. И все пак ви е трудно да обедините критичните инструменти за изграждане в съществуващия процес на изграждане.

При друг сценарий може да искате да мащабирате разработката, за да включите много екипи. И все пак, свързването и сложността в съществуващия монолит може да попречи на ефективния напредък. Това е така, защото хората са длъжни да стъпват на пръстите на другия. Тези реални проблеми могат да повлияят негативно на потенциала за доставка на всеки. В резултат на това клиентите могат да загубят висококачествено изживяване.

Традиционен монолитен софтуер

Древните монолити или монолитни системи са имали всичко обединено в една разгръщаема единица. Някои монолити могат да бъдат бързи за проектиране и лесни за разгръщане. Но те не са толкова гъвкави, защото най-малките промени често се нуждаят от пълно пренасочване. Тук говорим за микроуслуги. Те са по-популярна архитектурна концепция. Но микро интерфейсите се грижат за интерфейса. Вместо една значима, тромава фронтенд архитектура, имаме няколко малки части (модули). Разработвате всеки един изолирано.

Microservices възродиха старата идея за изграждане на по-малки софтуерни части за многократна употреба. Всяка част има само минимална връзка с друга. Всяко парче също е ефективно при извършване на едно нещо добре. По този начин те не споделят зависимости. Разработчиците също могат да работят върху тях и да ги внедряват независимо. Големи организации са използвали този архитектурен избор за своите проекти. Архитектурата на микроуслугите набира все повече позиции. Причината е, че той премахва ограниченията на монолитните бекендове.

Някои значителни предимства на микроуслугите включват:

  • изолиране на грешки
  • технологична независимост
  • ранно мащабиране
  • непрекъснато развитие и внедряване

Огромният успех на решенията от страна на сървъра не опрости начина, по който работи кодовата база на интерфейса. Той също така не се занимава с това как допълва бекенд услугите. Приложението за една страница (SPA) е популярно за превъзходна производителност, потребителско изживяване и преобразуване. Но SPA също разчитат на монолитна архитектура. С нарастването на SPAs тяхната поддръжка и внедряване стават бавни. Всяка малка промяна се нуждае от регресионно тестване. Това увеличава усилията при внедряването, което също води до високорискови изтичания на памет

Микроуслугите работят за справяне с проблемите с традиционната софтуерна архитектура. Това се случва чрез следване на модулна стратегия за развитие. Предната разработка може да се осъществи чрез концепцията за микроприложението. Оттук и името микро интерфейси. Но какво представляват микро интерфейсите? Микро фронтендите са подходът на микроуслугите към уеб разработката на предния край. Отново трябва да се запитаме защо разработчиците ги смятат за такива. Освен това, от какво се нуждае един разработчик, за да започне разработка на микро интерфейс?

Какво е микро фронтенд архитектура?

Микро интерфейсите описват модулния подход към уеб разработката. Едно приложение е разделено на своите страници и функции; всяка функция става отговорност от край до край на един екип. Архитектурата за многократна употреба, зависима от компоненти, използва множество части от код. Той комбинира тези компоненти, за да създаде монолитен фронтенд, който седи върху слой от бекенд услуги.

Микро-интерфейсът също гарантира, че всяка функция е индивидуално разработена и тествана. С микро интерфейсите кодовата база е много по-малка. Също така е кохезивна, което означава, че е удобна за поддръжка. Разединява функциите и страниците, позволявайки на независими екипи да работят върху тях. Сега можете да разберете защо е много по-лесно да надграждате части от приложение. Освен това е по-лесно да актуализирате и пренаписвате части от приложението, отколкото би било монолитно.

Примерна структура на приложение, която монтира множество микро интерфейси в едно контейнерно приложение. Приложенията могат да комуникират помежду си чрез обща шина за съобщения със стандартизиран интерфейс:

Кое да изберете – монолити или микрофронтове – и защо

От съществено значение е да решите дали да тръгнете по пътя на монолитна SPA или микро фронтенд архитектура. Това решение трябва да дойде преди да започне разработването на уеб приложения. Честно казано, микро интерфейсите не са подходящи за всеки проект. Те идват със собствен набор от предимства, но не са идеални за всеки случай.

Сложността и размерът на проекта са два критични фактора при вземането на това решение. Но по проект може да работи голям екип с подекипи. Всеки подекип ще работи върху отделни модули и функционалности. Архитектурата на микро интерфейса е подходящо решение. Малък или среден проект, който се нуждае от по-малко редовни издания или актуализации. Екипите също зависят един от друг за изданията. Тук те могат да изберат монолитна архитектура за уеб разработка отпред.

Разходите за приемане на микрофронтенд архитектура

Използването на микро интерфейси предлага предимства, подобни на микроуслуги. Важно е също така да се посочи цената на разработването на архитектура на микро интерфейси. Всичко си има цена в софтуерната архитектура. Някои внедрявания на микро интерфейс могат да доведат до дублиране на зависимости. Това увеличава броя на байтовете, които потребителите трябва да изтеглят. Също така, драматичното нарастване на автономността на екипа може да доведе до фрагментация в работата на екипа. Но това са управляеми рискове. Ползите от микро интерфейсите дори често надвишават разходите.

Тестване

Тестването не прави голяма разлика между монолитни интерфейси и микро интерфейси. По принцип методите за тестване на монолитен интерфейс се отнасят за отделни микро интерфейси. Така че всеки микро интерфейс трябва да има своя цялостен набор от автоматизирани тестове. Тази стратегия гарантира качество и коректност на кода. Очевидното несъответствие би било интеграционно тестване на различните микро интерфейси. Използвайте приложението контейнер за това. Това може да се случи с помощта на който и да е функционален/от край до край инструмент за тестване, който предпочитате (например: Cypress), но бъдете внимателни.

Функционалните тестове обхващат само аспекти, които може да не сте в състояние да тествате на по-ниско ниво от тестовата пирамида. Това означава, че модулните тестове трябва да покриват вашата бизнес логика и логика на изобразяване на ниско ниво. След това можете да използвате тестове за приемане, за да потвърдите, че сте сглобили правилно страницата. Например, можете да заредите напълно интегрираното приложение на определен URL адрес. Можете също така да потвърдите, че твърдо кодираното заглавие на съответния микро интерфейс е достъпно на страницата. Ако вашите потребителски пътувания обхващат няколко микро интерфейса, използвайте функционално тестване, за да ги покриете. Но се уверете, че тестовете за приемане се фокусират върху валидирането на интеграцията на интерфейсите. Това не трябва да оказва влияние върху вътрешната бизнес логика на всеки микро интерфейс. Единичните тестове трябва да ги покриват предварително. Договорите, управлявани от потребителите, могат да помогнат за директното уточняване на взаимодействията между микро интерфейсите.

Заключение

Кодовите бази на интерфейса стават по-сложни, създавайки нарастваща нужда от по-мащабируеми архитектури. Трябва да има граници, установяващи подходящите нива на свързване и сплотеност. Те са жизненоважни за домейни и технически единици. Трябва да е лесно да се мащабира доставката на софтуер в независими, автономни екипи. Този подход не е единственият. Има много случаи от реалния свят, при които микро интерфейсите предоставят тези предимства. Този подход работи както с наследени кодови бази, така и с нови. Бизнесът може да прецени дали микро интерфейсите са подходящи за тях или не. Въпреки това инженерството и архитектурата на интерфейса продължават да се развиват по вълнуващи начини. Всеки сериозен разработчик трябва да бъде в крак.

Видео

Първоначално публикувано на https://selleo.com.