Zasady architektury mikrofrontendów

Mikrofrontendy przenoszą idee mikrousług do interfejsu użytkownika: duża aplikacja jest dzielona na niezależnie rozwijane i wdrażane części, za które odpowiadają osobne zespoły, a następnie składana w jedno doświadczenie użytkownika.

Pojedynczy duży frontend oznacza, że każdy zespół pracuje w jednym repozytorium kodu, koordynuje wydania i korzysta z jednego procesu budowania. Wraz z rozwojem organizacji staje się to wąskim gardłem — pojawiają się powolne buildy, konflikty podczas scalania i sztywno ustalone cykle wydań.

Kluczową ideą jest odpowiedzialność od początku do końca. Zespół odpowiada za swoją część interfejsu — od kodu po wdrożenie — oraz zarządza własnym repozytorium, potokiem i środowiskiem uruchomieniowym, dzięki czemu może działać bez czekania na innych.

Zespoły dzielą pracę według możliwości biznesowej (Checkout, Search, Profile), a nie według warstwy technicznej. Każdy wycinek zawiera własny interfejs, logikę i dostęp do danych związanych z daną możliwością.

Każdy mikrofrontend jest wdrażany według własnego harmonogramu. Zespół Search może wdrażać zmiany dziesięć razy dziennie bez ingerowania w Checkout. Wydania są od siebie niezależne, co zmniejsza ryzyko i potrzebę koordynacji.

Zespoły mogą wybierać różne frameworki dla poszczególnych wycinków. W praktyce większość organizacji ujednolica technologie (np. wszędzie stosuje Vue) na potrzeby wspólnych narzędzi, ale architektura dopuszcza różnorodność tam, gdzie jest ona uzasadniona.

Jednym ze sposobów łączenia wycinków jest integracja na etapie budowania: każdy mikrofrontend jest publikowany jako pakiet, a aplikacja kontenera instaluje je jako zależności i buduje razem.

Integracja na etapie budowania jest prosta, ale uzależnia od siebie wydania: aby wdrożyć nową wersję Checkout, aplikację kontenera trzeba ponownie zbudować i wdrożyć. Traci się w ten sposób prawdziwą niezależność wdrażania.

Integracja w czasie działania ładuje mikrofrontendy w przeglądarce podczas działania aplikacji — kontener pobiera kod remote'a, gdy jest on potrzebny. Każdy remote jest wdrażany niezależnie, a kontener pobiera najnowszą wersję bez ponownego budowania.

Najważniejszą techniką integracji w czasie działania jest Module Federation: funkcja procesu budowania, która pozwala jednej aplikacji udostępniać moduły, a innej pobierać je przez sieć w czasie działania, ze współdzieleniem wspólnych zależności. Będą Państwo korzystać z niej w kolejnych lekcjach.

Integrację na etapie budowania warto stosować w małych zespołach, które chcą zachować prostotę i korzystać z jednego wdrożenia. Integrację w czasie działania (Module Federation) należy wybrać, gdy priorytetem są niezależne wdrażanie i autonomia zespołów, a dodatkowa złożoność operacyjna jest akceptowalna.

Proszę sprawdzić swoją wiedzę na temat zasad dotyczących mikrofrontendów.

Poznali Państwo zasady dotyczące mikrofrontendów:

• Duży interfejs jest dzielony na niezależnie zarządzane i wdrażane wycinki, które są łączone na potrzeby użytkownika.
• Autonomia zespołu: odpowiedzialność od początku do końca za pionowy wycinek biznesowy.
• Niezależne wdrażanie: każdy wycinek jest wdrażany według własnego harmonogramu.
• Różnorodność technologii jest opcjonalna; większość zespołów ujednolica technologie.
• Integracja odbywa się na etapie budowania (prosta, ale uzależniająca od siebie wydania) albo w czasie działania (Module Federation, prawdziwa niezależność).