Microfrontendy w module federation to kłamstwo!

W dzisiejszym odcinku powiemy wam dlaczego mikrofrontendy w module federation to kłamstwo. Ja nazywam się Jakub Pawlak. Ja jestem Aleksander Lubych. A to Subiektywny Frontend. Chciałbym zacząć od tego, że ja w 2018 roku trafiłem na NG Poland i tam była prezentacja Manfreda Steyera. Prezentacja o mikrofrontendach. I to zmieniło zupełnie moją karierę. Na początku, jakby na tej prezentacji, była mowa o webkomponentach i faktycznie wtedy to mi się bardzo przydało do mojej pracy i zacząłem robić webkomponenty. Ale już rok później pojawił się nowy gracz.

New kid on the block. Module Federation. I to było kłamstwo, że to są Microfrontendy. I teraz to wiem. A jaka była twoja historia? Jak dotarłeś do tego, że Module Federation to kłamstwo? No, akurat do tego dotarłem już tutaj, w Becu, bo nie miałem instrukcyjności przed Becem. Wcześniej pracowałem na Microfrontendach, ale akurat to były nieco inne Microfrontendy, gdzie było renderowanie po stronie backendu, więc Shell był taką hybrydą. Miał za zadanie ściągnąć konfigurację microfrontendów po stronie serwera, a potem po prostu wyrenderowanie tego już na froncie.

I cały routing był też po stronie serwera. Brzmi bardzo skomplikowanie. To było bardzo skomplikowane. No i to było fajne. No dobra, dobra, ale to w ogóle nie jest module federation. A tutaj minęło 7 lat i wchodzimy sobie teraz na stronę module federation i to cyk, pyk. Microfrontend architecture. No i teraz pytanie w takim razie, po co my w ogóle o tym mówimy, skoro tutaj mówią, że mikrofrontendy, a my mówimy, że nie mikrofrontendy, to co, może od razu wkoczymy w temat. To jak to z tym module federation i mikrofrontendami jest? Co to jest w ogóle za mit, że module federation to mikrofrontendy? No takie odważne stwierdzenie, prawda? Bo wszyscy mówią o tym, że to mikrofrontendy, że to daje taką niezależność, no bo na tym tak naprawdę polegają mikrofrontendy, a tak się okazuje... Tutaj tu w trące już mówiliśmy o mikrofrontendach, więc jak ktoś nie odrobił lekcji, to tutaj odcinek...

Trzeba obejrzeć. A się okazuje, że tak naprawdę z tym module federation nie jest do końca tak, jakby się wydawało, że to takie są pełnoprawne, ja bym tak to nazwał, pełnoprawne microfrontendy, gdzie po prostu w pełni niezależnie budujesz sobie aplikacje i po tym je sobie serwujesz, rylisujesz. No właśnie, bo ja, no dobra, umówmy się, trochę tytuł jest clickbaitowy. Bo module federation oczywiście jakby spełnia niektóre założenia mikrofrontendów, bo jest ich kilka. Tak jest. Ale nie wszystkie, po prostu no ma pewne swoje ograniczenia. I właśnie ta świadomość tych ograniczeń, wydaje mi się, przy module federation jest kluczowa.

Bo jeżeli Ty wejdziesz w module federation i będziesz przez jakiś czas z tym pracować i budować nad tym platformę lub system, a potem się okaże, że jednak to nie jest to, co Ci Czego potrzebujesz? No to wyjście z tego będzie bolesne. No właśnie, bo zacznijmy też od tego... Dobra, zacznijmy. To dużo powiedziane, bo już trochę o tym mówimy, ale... Trzy razy zaczynamy, Jakub. Dobrze nam idzie. Ale module federation w ogóle to jest taki system, biblioteka, która służy do share'owania po prostu i lazy loadowania. Paczek javascriptowych. Koniec końców to po prostu polega na tym, że możemy asynchronicznie załadować sobie części aplikacji i w ten sposób możemy załadować części aplikacji, które stanowią te nasze mikrofrontendy.

Ale możemy też używać web-komponentów i użyć do tego module federation. Czyli dalej mamy pewne reużycie, jakby zyskujemy z tego module federation pewne reużycie rzeczy, ale jakby koniec końców taki główny nurt to jest właśnie to, co jest promowane przez NX-a, przynajmniej w naszym świadku angularowym. Więc tutaj trochę właśnie widzę, że procesuje się. No tak, zawiściłem się trochę, bo zacząłem się zastanawiać nad jedną rzeczą. Już nie chcę odjeżdżać, bo ty mówisz o tych web-komponentach, ale już nie chcę odjeżdżać, bo jak zaczniemy wchodzić w samą implementację i zaczniemy mówić, czym są Microfrontendy na froncie,

I to, jak definiujesz i to, że musisz mieć routing na przykład tych Microfrontendach i ten routing jakoś porzenić, bo tak teraz zacząłem sobie myśleć o tych web-komponentach i tym POC, które robiliśmy u nas i po prostu się zawiesiłem, Jakub. No bo to jest właśnie skomplikowany temat, bo module federation samo w sobie jest do ładowania i lazy-loadowania i share'owania paczek. Ale możemy to użyć też w różnych kontekstach. A musi być coś, co to orkiestruje i coś, co tym zarządza i tym routingiem zarządza, więc tam są jeszcze inne aspekty tego systemu mikrofrontendowego. Ale wracając do clou. Monorepo, coupling na poziomie wersji frameworka. Wyobraźmy sobie, że jesteśmy w Angularze. No w React'cie jest dokładnie tak samo.

Jesteś zależny od tej wersji, w której jest twój shell, czyli ten host, który serwuje te Microfrontendy. No i teraz nie masz szansy, żeby zaserwować jakąkolwiek inną wersję, przez co pójście w multi repo jest poniekąd trochę strzałem w kolano, ponieważ upgrade frameworka wtedy robi się niezwykle bolesny. Więc zostajesz przy Monorepo przeważnie. Tak. I ja bym powiedział, że po prostu module federation w Monorepo daje super możliwości, jeśli chodzi o czas i szybkość developmentu i performance, właśnie optymalizację samej aplikacji.

I to jest super perfekcyjna para. Bardzo fajnie to działa. Ale w momencie, jak zaczynamy działać z module federation i wchodzimy w multirepo, No to jest bolesne przeżycie. Tak się nie robi. To znaczy, to właśnie jest takie pozorne unikanie zależności, że mamy trochę Microfrontendy, ale jak robimy update jakiejś biblioteki, no to zróbmy ją wszyscy razem, wszyscy razem za rękę, weźmy te wszystkie nasze 20-50 repozytoriów. Uhu, niezależność! Tak, tak, tak. Dlatego module federation jakby w tym setupie z Monorepo, który Elnix promuje, jest bardzo fajny. To działa. I można module federation użyć też w różnych kontekstach.

Zakrywam się. To jest dzisiaj jakoś ciężko, dzisiaj jestem polskim. Ciężko. Ukrywamy się za feature-toggle'em, no i tak naprawdę mamy czystą... Sytuację sterujemy tą widocznością przez Feature Toggle. I tak można uzyskać tą niezależność, ale to nie zawsze jest takie proste. Szczególnie jeżeli masz monorepo, które było rozwijane bez trunk base od samego początku i bez właśnie Feature Toggle i są jakieś pewne naleciałości. Stąd ta decyzja z tym module federation przy Microfrontendach musi być świadoma. Jak byśmy to mogli podsumować z tymi mikrofrontendami i module federation?

Bo my tak sobie rozmawialiśmy o alternatywach i tak dalej, ale ja bym powiedział, że to są takie trochę nie alternatywy do module federation, tylko alternatywy do sposobu ładowania mikrofrontendów i samo module federation jakby nie stanowi żadnej przeszkody i jakby dalej możemy to używać. Tak jak wcześniej powiedzieliśmy, że to jest doskonałe narzędzie. Tak, ja bym właśnie to tak podsumował w takim jakby przeglądzie tego, jak możemy to module federation, do czego to zapiąć i możemy właśnie użyć web komponentów, single SPA, możemy robić takie lazy loadowane moduły, to też jest ok, ale wtedy musimy mieć monorepo, a możemy też użyć iframe'ów. No właśnie. I tutaj chciałem pozdrowić Jurka, mojego kolegę, który, nie wiem czy to było 8 lat temu, jeszcze w poprzedniej pracy, pracował nad taką fajną aplikacją, gdzieś tam jakiś Dashboard, drag and drop, ale mieli tam iFrame'y, mieli jakiś Event Bus i tak mi o tym opowiada i mówię, no ale to w sumie to tak wszystko brzmi jak Microfrontendy.

On mówi, no... No w sumie to tak. Czyli już pracował 8 lat temu na tym... Ale nie brzmiało tak fajnie. I nie chwalił się tym, że to są Microfrontendy, tylko po prostu użył kilku iframe'ów i załatwiło mu to jakieś tam problemy, ale nie chodził na konferencje i... I nie opowiadał o tym i wszyscy nie chcieli tego robić. Tylko jak ktoś słyszał, że iframe'y, co? No bo be! Iframe'y! No właśnie, więc oczywiście mamy też alternatywę do takich rozwiązań typu właśnie to, co wspomniałeś, czyli jakieś tam generowanie tego po stronie serwera, ale jakby to nie jest dzisiaj tematem rozmowy. Myślę, że możemy do tego też wrócić. Ale ja bym ci chciał pokazać jeszcze taki formularz i zrobimy taki rating.

I ten formularz zrobiłem z moim przyjacielem o 3 mini. Nie napisałem tam ani linijki kodu. Ale to przyjaźń kwitnie. Kwitnie, kwitnie. Nie napisałem linii kodu, nie napisałem nawet pytań, nie napisałem nic w zasadzie, więc przejdziemy sobie przez takie pytania, ale to jest... Dobra, z tym, że nie przechodziłem przez te pytania, to kłamstwo. Jakby chciałem po prostu z tobą przejść przez ocenę, czy module federation z... Lazy loadowaniem modułów czy komponentów w taki sposób najprostszy, jak NX to proponuje, to czy to są mikrofrontendy, czy to nie są mikrofrontendy. Super. I zacznijmy od pierwszego pytania. Czy mamy niezależną bazę kodu? Nie. Autonomiczny rozwój i wdrażanie. Czy zespoły mogą wdrażać tak niezależnie od siebie, w którym momencie chcą?

No, mogą, moim zdaniem. No właśnie, wspomniałeś o feature togglach, mogą. Jest taka możliwość. Czy każdy Microfrontend w takim setupie jest dedykowany, interdyscyplinarny zespół? Myślę, że tak. No tak. Czy zespoły i czy Microfrontend jest samowystarczający i jest w całości zaenkapsulowany? Czyli, że się nie rozlewa. No nie. No właśnie, w ogóle nie. To jest... Nie, bo module federation i jeśli coś lazy loadujemy, to nam się wszystko rozlewa. Mamy w ogóle na przykład z serwisami angularowymi, mamy w ogóle jeden root injector. I możemy, mamy jeden store.

Nie mamy totalnie żadnej enkapsulacji. Czyli nie. Domenowość i ścieżka użytkownika. Czy dany Microfrontend skupia się na danej domenie biznesowej albo ścieżce użytkownika? To trochę jest z tym zespołem dedykowanym powiązane. No ja myślę, że to jest kwestia tego, jak to będzie organizowane. Integracja. Czy Microfrontendy są integrowane w spójne aplikacje i mają na przykład coś takiego jak Bridge, jakiś tam even bus? Myślę, że tak. I to nawet ja bym powiedział, że ta integracja na poziomie module federation i tego lazy loadowania jest taka nawet, jakby to powiedzieć, że ta integracja jest bardziej spójna. To znaczy masz mniejsze ryzyko np.

przez to, że nie są enkapsulowane, jakichś konfliktów w styli. Jakby wszystko jest jedną spójną aplikacją, a po prostu lazy loadujemy komponenty. Technologie. Czy mogą używać różnych technologii? Odporność, izolacja błędów. O i to jest w ogóle ciekawy temat. Czy awaria mikrofrontendu wpływa na aplikację, czy mamy jakąś izolację? To jest doskonały przykład właśnie przy module federation, nie? Nie. Że nie. Nie, no po prostu się rozlewa. Nie masz tej pełnej izolacji. Nie, nie w ogóle. Nie jestem knife'em, kurczę, no wszystko wskazuję na knife'ie. No nie. Obsługa błędów. Czy Microfrontend łagodnie reaguje na błędy, zapewniając ciągłość działania interfejsu?

Czyli, że jak wywali się jakiś jeden Microfrontend, czy zablokuje całą resztę? Powiem ci, że jest taka szansa. Jest. Jest taka szansa. To jest w ogóle... No nie no, to nie są mikrofrontendy. Nie tędy droga, nie w tym wypadku. Czy zespoły się mogą skalować? Czy możemy urównoleglić pracę? No w zasadzie tak. W zależności od tego, jak to będzie zorganizowane, nie? No właśnie. To o tym przyrozumieliśmy wcześniej. Czyli mamy 5 punktów na 10. Czyli trochę są mikrofrontendy, trochę nie są. Dopiero zaczynasz przygodę z mikrofrontendami, Jakub. No, dokładnie. Jakieś słowo podsumowanie, czy coś masz do siebie do dodania?

No i na przykład ktoś wykona robotę za was, na przykład taki platformowy team, który zrobi update całego frameworka na całe monorepo. No i dobre! To, co chciałem zaznaczyć, to jest to, że module federation jako taki byt, który rozwiązuje wszystkie problemy, które niby oferują mikrofrontendy, no to trzeba z tym uważać i po prostu pamiętać o tym, co jest najważniejsze w tym setupie mikrofrontendowym i tego, czego odczujemy. W setupie waszym mikrofrontendowym. Oj, to jest super ważna rzecz, bo nasz setup nie jest waszym setupem. Jakub, właśnie to jest bardzo ciekawe, że co ja przechodzę z organizacji do organizacji, z firmy na firmę, każdy te microfrontendy robi po swojemu i każdy robi to pod siebie.