- Постепенна миграция позволява на екипите да „задушат“ наследените монолити, като заменят високоценни фрагменти от потребителския интерфейс без рисковани пълни пренаписвания.
- Организационна автономия се постига чрез съгласуване на микрофронтендовете с бизнес поддомейните, което позволява независими цикли на внедряване.
- Технически състав може да се обработва чрез фрагменти от страна на сървъра, федерация на модули или интеграция на JavaScript по време на изпълнение, в зависимост от нуждите от производителност.
Нека бъдем реалисти: повечето големи корпоративни уеб приложения са по същество гигантски топки кал. Когато имате масивен монолитен фронтенд, мащабирането на разработката ви се превръща в кошмар, защото всички си стъпват на пръстите и една-единствена грешка може да провали цялото шоу. Идеята за пълно пренаписване е изкушаваща, но в реалния свят това обикновено е самоубийствена мисия, която отнема години, преди потребителите да видят дори една-единствена полза.
Ето къде идва магията на постепенното внедряване . Вместо да превключвате с един превключвател, започвате да издълбавате монолита парче по парче. Като третирате вашия фронтенд като композиция от независимо доставяни приложения, можете да модернизирате своя технологичен стек и да дадете възможност на екипите си да се движат по-бързо, без стреса от високорисково внедряване с голям взрив. Всичко е въпрос на намиране на златната среда между стабилност и гъвкавост.
Стратегия за пробиване на фрагменти
Един от най-готините начини за справяне с преход към legacy shell е чрез техника, наречена „ пробиване на фрагменти“ . Представете си, че имате бавно зареждащо се React приложение; вместо да чакате цялата обвивка да се стартира, можете да рендирате фрагменти от страна на сървъра (използвайки инструменти като Cloudflare Workers), които са интерактивни почти мигновено. Тези фрагменти първоначално се поставят на най-горното ниво на HTML кода и след това се „пробиват“ или преместват на правилното им място в DOM, след като legacy shell най-накрая ги настигне.
Този подход е спасение за подобряване на Core Web Vitals, защото съкращава времето за интерактивност. Например, можете да превърнете формуляр за вход в самостоятелен фрагмент. Потребителите могат да започнат да въвеждат своите идентификационни данни, преди основното приложение дори да съществува в браузъра. За да се осигури безпроблемност, може да се използва Message Bus като независим от рамката начин тези фрагменти да общуват със старото приложение, без да се създава тясна връзка.
Архитектурни подходи към интеграцията
В зависимост от вашите цели, има няколко начина за съединяване на тези части. Съставянето на шаблони от страна на сървъра е старомодният, но надежден метод, използващ неща като Nginx за включване на HTML фрагменти. Ако искате повече гъвкавост, интеграцията по време на изпълнение чрез JavaScript позволява на контейнерно приложение да изтегли пакет и да извика глобална функция за рендериране. За тези, които харесват вградените възможности на браузъра, уеб компонентите предлагат стандартизиран начин за дефиниране на персонализирани елементи, които обвивката може просто да създаде.
Съвременните магазини все повече се насочват към Модулна федерация . Това позволява на приложението динамично да зарежда модули от друга компилация по време на изпълнение. Чрез използване на модел на потребител и доставчик можете да споделяте сингълтони като React или Vue, така че потребителят да не се налага да изтегля една и съща рамка пет пъти. Златният стандарт за избягване на „ад на зависимостите“ обаче често е монохранилище , което гарантира, че всички микрофронтенди се тестват спрямо едни и същи версии на библиотеките, преди да влязат в производство.
Избягване на често срещаните капани
Лесно е да се прекали и да се създаде анархия в микрофронтенда . Често срещана грешка е да се мисли, че микрофронтендовете са просто „големи компоненти“. Бутонът е компонент; процесът на плащане е микрофронтенд. Ако започнете да правите всеки малък елемент от потребителския интерфейс отделен разгръщаем елемент, просто добавяте ненужна оперативна сложност . Винаги трябва да съобразявате границите си с бизнес поддомейните , а не с техническите слоеве.
Друг капан е изкушението да използвате множество рамки . Само защото можете да стартирате Angular, React и Svelte на една страница, не означава, че трябва. Това намалява производителността и фрагментира вашия екип от таланти. Единственият път, когато това има смисъл, е по време на стратегия за миграция или след придобиване. За да предотвратите прекаленото преплитане на приложенията ви, избягвайте споделено глобално състояние. Вместо това, разчитайте на еднопосочен поток от данни и комуникация, управлявана от събития, за да запазите екипите наистина автономни.
Компромисът: Автономия срещу режийни разходи
Няма такова нещо като безплатен обяд в архитектурата. Избирайки микрофронтендове, вие заменяте атомни издания с независими. Това означава, че може да се сблъскате с неравномерност на версиите , при която различни части на страницата изпълняват различни версии на споделена библиотека. Ще видите и увеличение на общия размер на полезния товар, ако не внимавате със споделените зависимости.
От организационна гледна точка ще ви трябват повече CI/CD канали и по-добра наблюдаемост. Но за голяма компания ползата е огромна: намалено когнитивно натоварване за разработчиците и възможност за създаване на нови екипи, които могат да притежават функция от идеята до производството. Ако установите, че множество микро-фронтенди търсят една и съща крайна точка на API, това е знак да преоцените границите си или да въведете Backend-for-Frontend (BFF), за да обедините тези повиквания и да предотвратите разрастването на API.
