Ten setup zniszczy Twój monolit – NX + Micro Frontendy w 2025 🤯

To zanim przejdziemy do kodu, chcielibyśmy Wam pokazać tylko, do czego dążymy. Chcielibyśmy mieć Shella, czyli aplikację hosta i dwie aplikacje Micro Frontendowe. To przejdźmy do kodu. I tutaj zrobimy małe oszustwo, bo nie będziemy tego wywoływać, bo to chwilę trwa, a to jest wszystko dobrze udokumentowane, czyli jak postawić NXowe monorepo. Wystarczy w terminalu wpisać tą piękną komendę Create NX Workspace. Następnie zostaniemy zapytani o parę rzeczy i w zasadzie tutaj wybierajcie co chcecie. My oczywiście wybraliśmy sobie angularową aplikację plus Jesta, pominęliśmy testy end-to-end i wylądowaliśmy z takim oto projektem.

Warto zauważyć, mamy w kilku kliknięciach bardzo potężny setup, który tak naprawdę nie wymagał zbyt wiele od nas. To patrz teraz. Teraz wpiszemy magiczną komendę. Ciach. I generujemy cały setup Micro Frontendów. Tak. I zwróćcie uwagę, jak ta komenda wygląda. Wskazujemy tutaj, jakiej technologii ma być host. Automatycznie będzie taka sama technologia wybrana dla Micro Frontendów. Oczywiście wskazujemy, jak się ma nazywać host, czyli w naszym wypadku to jest Shell, a remote, czyli Micro Frontend, będą się nazywać Dashboard i Settings.

I przeszliśmy CLI, Create, Create, Create i po chwili Boom! Mamy już cały mikrofrontendowy setup gotowy. Czyli mamy hosta i dwa mikrofrontendy. Wow! No dobra, to wystartujemy w takim razie aplikację. Wywołujemy npx nx-serve shell. I teraz Angular tam zamieli i postawi nam cały setup. I tu ciekawostka, bo wpisując tą jedną komendę, odpalając shella, odpali nam też od razu dodatkowe mikrofrontendy, ponieważ NX sobie to ogarnie. Czyli nie musiałeś otwierać kolejnych terminali dla poszczególnych mikrofrontendów, co jest dość fajne.

No i teraz wchodzimy sobie na naszą aplikację i wita nas Shell. I mamy tutaj Dashboard i mamy nasz Settings, czyli wszystkie Micro Frontendy działają. Tutaj widzicie po prawo Network, czyli Inspektor Chroma i przefiltrowujemy po czymś takim, co się nazywa Remote. To jest taki pliczek dla Module Federation, który zawiera w zasadzie definicję tego, co tam w tym naszym Micro Frontendzie siedzi. I możecie zauważyć, że jestem aktualnie na localhostie 4200, tak jak defaultowy localhost dla angularowej aplikacji, ale Remote Entry został załadowany z hosta. 4201, a kolejne Remote Entry 4202. I to są nasze Micro Frontendy.

I co tu się wydarzy? Nie wiem, choć się domyślam. Dostajemy taką apkę, która jest oczywiście zaserwowana na local hostie. Czyli NX Graph pozwala nam sprawdzić, jak wyglądają zależności w naszym repozytorium. Czyli widzimy tutaj nasze trzy aplikacje Shell, które jest zależne od dashboardów i settingsów. I tu warto wspomnieć, że dashboard nie wie nic o swoim Shellu. Czyli moglibyśmy mieć tych Shellów kilka. Tak to na przykład wygląda u nas, prawda? Dokładnie tak. Niesamowita sprawa. No dobra, ale to tak jakoś wygląda bardzo prosto, to może byśmy coś dodali do naszego setupu. I teraz wygenerujmy sobie jakąś bibliotekę.

Czyli odpalamy znowu nowy terminal i generujemy nx generate lib i tutaj w folderze libs będziemy generowali shell config. Teraz nas zapyta, jaki generator. My używamy NX-owego angularowego generatora. Jest i ciach. Mamy teraz nową libkę i to jest shell config. I jak teraz odświeżę sobie nasz graf, a nawet nie odświeżałem, sam się odświeżył, to mamy już nasz shell config. No i dobra, ale co tam się zmieniło w naszym repo? Bo to nie tylko jest jedyna zmiana, że tutaj się pojawiły nowe pliki.

Istotne jest też to, że w ts-config-base pojawił nam się nowy wpis pod paths. Czyli NX sobie dodaje takie aliasy npmowe po to, żeby łatwiej importować rzeczy między projektami. No dobra, i co my mamy w tym Shell Configu? A mamy jakiś prosty komponencik, Shell Config. No to może go zaimportujemy sobie do... A czemu nie do Shell'a? Ciach. Wchodzimy w aplikację i dodajemy tutaj do importów. Nie musimy go wywoływać, wystarczy, że zaimportujemy. I w importach mamy już subiektywny Shell Config component. Co się zmieniło w naszym grafie? No jasno, widzimy, że mamy teraz zależność Shell'a do Shell Config'u, co oczywiście jest oczywistością oczywistą.

K***a, oczywiście, że tak. No dobra, no to idziemy dalej w takim razie. Shell Config w sumie jest fajnym komponentem, więc dodajmy go jeszcze do dashboardu, bo czemu by nie, skoro to jest Config. No i wszystko się share'uje, prawda? No właśnie, to Config jest w końcu. To config możemy używać w kilku różnych miejscach. No i... Proszę bardzo. Proszę bardzo. I wszystko jest. Więc NX Graph jest super fajnym narzędziem, tylko czy naprawdę shell config powinien być zależnością dla dashboarda? No dobra, no to może w takim razie spróbujmy zgłębić temat Module Boundaries. Module Boundaries to jest taki w zasadzie eslintowy plugin od NX-a.

I co on robi, Aleksie? Module Boundaries pozwala nam blokować właśnie niechciane zależności, żeby jasno kontrolować, które warstwy, które rzeczy mogą od siebie zależeć. No dobra, no to wszedłem w nasz ESLint Config, który NX wygenerował dla mnie i widzę tutaj taką regułę NX i Enforce Module Boundaries. I to jest dokładnie to, o co nam tutaj chodzi. Mamy tutaj taki atrybut depconstraints i to, co będziemy chcieli teraz zrobić, to zablokujemy możliwość importowania shell configa w innych naszych remote'ach, ponieważ NX wygenerował nam trzy piękne aplikacje, ale jedna z nich jest hostem, a dwie pozostałe są remote'ami, czyli są micro frontendami i one nie powinny wiedzieć nic o sobie, ani też nie powinny wiedzieć nic o

Naszym hościem, czyli naszym szalu. No dobra, no to jak to w takim razie zrobić? Przejdziemy razem przez ten proces. Czy teraz musimy oznaczyć nasze projekty tak, żeby miały jakieś tagi? Dodajmy tutaj tag, jeżeli jesteśmy w Shellu, dodajmy tag Shell, tak dla ułatwienia. A jeżeli jesteśmy w Remote'ach, no to w takim razie dodajmy po prostu tag Remote. Dobra, i jeszcze settings też oznaczymy sobie naszym pięknym nowym tagiem Remote. Ops. I teraz jeszcze przydałoby się nam oznaczyć naszą lipkę. Tak jest. Skóra nasza lipka jest stworzona pod shella, no to też musi mieć tak shell. Dobra.

No i co? I to już wszystko? W tym momencie to, jeżeli chodzi o projekty same, to tak, wystarczy dodać tagi, ale następnie musimy skonfigurować Model Bundle z naszym ESLint Config. No dobra, no to co mam robić? Tutaj musimy dodać Source Tag, który się będzie nazywać Shell. Dobra, no to dodajemy Shell. Domyślam się, że też musimy zmienić, coś dodać dla hosta. Tak jest. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy.

Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Dobra, no to kopiujemy i wklejemy. Error, error, warning, error. Project tagged with shell can only depend on lips. Tagged with shell. No i popsuliśmy. I właśnie to chcieliśmy, prawda? No dobra, no to jak teraz to naprawimy? Teraz chcemy dać dodatkową konfigurację, która powie, że shell może zależeć od remota, ale nie na odwrót, prawda? Dobra, no to...

Możemy dodać tutaj remote. Tak jest. To zróbmy jeszcze raz linter. No i dalej coś. Coś nam krzyczy. Coś nam krzyczy. Zobaczmy, co nam krzyczy. Dashboard, project, tag with remote, on remote. Zobaczmy. Nasz lint wykrył, że jest jakaś zależność w remoncie do liby, które są przeznaczone tylko dla shell'a. I to jest dokładnie to, dlaczego te module bundles robimy. Teraz spójrzmy na nasz graf. Tak jak Jakub wcześniej wspomniał, to nie jest to, do czego dążymy. Nie chcemy mieć circular dependencies, nie chcemy mieć ukrytych dependencji pomiędzy shell'em a micro frontend'em.