Micro Frontends - a może jednak ma to (czasami) sens?

Wszystko zaczęło się od monolitu i tak pewni by się skończyło, ale …

Nie pałaliśmy zbytnio chęcią do pójścia w stronę micro frontend’ów. Natomiast wymagania w projekcie tak pokierowały naszymi wyborami, że postanowiliśmy spróbować.

Rozmawiamy o naszych doświadczeniach:

• jakie są mocne strony micro frontend’ów?
• jakie są wady?
• czy narzędzia pomagają czy przeszkadzają?
• czy warto wchodzić w temat?

Zapraszam do wysłuchania rozmowy na Spotify, Apple Podcasts, Google Podcasts i poprostujs.pl

Transkrypt:

Marek Piechut

Witam panie Bartku

Bartek Witczak

Witam panie Marku.

Marek Piechut

No dobra chciałbym żebyśmy dzisiaj, przy nowej formule, porozmawiali trochę o temacie,tylko z takiego punktu widzenia naszego osobistego, bo zaczęliśmy jakiś czas temu robić mikro frontendy. Broniliśmy się przed nimi kopytami wszystkimi, przednimi zanimi i tylnymi i w ogóle. No ale zaczęliśmy robić te mikro frontendy pod naciskiem, presją zewnętrzną. Trochę jakby nasze podejście też jest inne niż takie ogólnie chyba uprawiane w internetach. I chciałbym żebyśmy sobie właśnie o tym pogadali nieco. Co ty o tym myślisz, co ja o tym myślę, jakby co nam wyszło co nam nie wyszło i czy to jest w ogóle coś, co jest warte pościgu w dzisiejszym świecie nowości.

Bartek Witczak

No dobra. To jest bardzo fajny temat i chciałbym tylko na początku żebyśmy nadali taki przynajmniej lekki ogólny kontekst tego naszego projektu. Mniej więcej jak to wygląda i dlaczego w ogóle jakby powiedzmy politycznie zdecydowaliśmy się zrobić mikro frontendy.

Marek Piechut

Zostaliśmy zdecydowani do zrobienia mikro frontendów. No dobra. Nasz projekt ma trochę modułów, trochę na backendzie już jest podzielony na wiele serwisów, które domenowo są w miarę rozdzielone. I te rzeczy jakby nie bardzo nam pasowały też razem na frontendzie do końca, żeby razem je mieszać ze sobą. I nie chcieliśmy stworzyć takiego monolitu frontu całkowicie bo tam zaczynało się tych rzeczy robić dosyć dużo. Więc doszliśmy do wniosku, że w sumie podzielimy go tam na mikro frontendy. Tak, zamiast budować go z jakichś tam podmodułów itd. no to pociachajmy już go na mikro frontendy, gdzie te systemy frontendowe są zupełnie rozłączne.

Bartek Witczak

OK to tylko taki jeszcze lekki kontakt z mojej strony. Ogólnie powiedzmy, że na początku budowania mieliśmy dwie aplikacje frontendowe-jedną na przygotowanie, drugą na wykonanie formuły i teraz trafiliśmy na sytuację gdzie rzeczy z tego przygotowania potrzebowaliśmy jakby rzeczy z jednego modułu musieliśmy wykorzystywać w drugim. No i zaczęliśmy standardowo czyli po prostu skopiowaliśmy sobie jakiś kawałek. No ale okazało się, że tych kawałków jest trochę więcej.

Marek Piechut

Metoda copy-ego paste-a się okazała nieefektywna.

Bartek Witczak

Dokładnie dokładnie. Ale to też jest ważne, że tak przy pewnej powiedzmy, że skali, bo jakby dopóki to było tak, że musieliśmy ten jeden element skopiować to to było całkiem jeszcze okej, nie było z tym jakiegoś szczególnego problemu. Okazało się, że po prostu coraz więcej jest tych elementów, które będą wspólne dla obu modułów, no i jakoś to trzeba ogarnąć.

Marek Piechut

Tak, no i nie chcieliśmy też eksplozji commonów, że nie chcieliśmy mieć mega common modułu, który ma 1500 komponentów i one są współdzielone przez przez aplikacje gdzieś tam, w różnych miejscach. Tym bardziej, że musieliśmy mieć już dwie aplikacje bo to jakby było nie negocjowalne.

Bartek Witczak

Tak, to było nie negocjowane i to już była taka powiedzmy że sytuacja zastana, że są dwie osobne aplikacje, całkowicie osobne ale jakby mimo wszystko chcemy w jakimś sensie współdzielić sobie jakieś części kodu.

Marek Piechut

No i dlatego teraz doszliśmy już do czterech? Cztery chyba mamy aplikacje, które się mash up-ują do dwóch. Powiedzmy tych dwóch, które były początkowo, no dobra do trzech bo to też nie jest prawda do końca ale jakby poszliśmy tak, że całkowicie odizolowaliśmy od siebie te rzeczy, czyli każdy frontend ma swój projekt praktycznie całkowity, każdy frontend jest deployowany w ogóle na osobnym dockerze itd. i gada sobie sam z beckendem, sam ma swoje biblioteki. Generalnie w niczym to nie przeszkadza żebyśmy mieli różne wersje różnych bibliotek, żebyśmy mieli kawałki, tak jak w klasycznym mikro frontendzie, czyli żebyśmy mieli część UI we VUE, część UI w React-cie, część w jQuery. Nic w tym nie przeszkadza. U nas to i tak ostatecznie się skończyło tym, że mamy wszędzie React-a bo bardziej rozwiązywaliśmy problem właśnie taki architektoniczno-organizacyjny niż problem tego, że chcemy mieć różne technologie. I ostatecznie mi się wydaje, że wyszło to całkiem spoko chociaż byliśmy w dużym stresie, nie bez problemów tak że to też sobie pogadamy trochę, że jakieś rzeczy nadal mamy nierozwiązane i bolą nas i chcielibyśmy je jakoś rozwiązać ale nie ma kiedy.

Bartek Witczak

Tak jest. Plus, sytuacja jest taka, że aktualnie są te dwie aplikacje frontendowe, te dwie aplikacje mają swoje elementy, swoje komponenty, swój kod i dodatkowo te dwie główne aplikacje ładują te pozostałe komponenty.

Marek Piechut

Ja tak z grubsza jeszcze powiem jak to jest zrealizowane u nas, bo trochę jest podejść różnych, które renderują te rzeczy. No i my zrobiliśmy sobie tak od zera to taką metodą, że mamy każdy ten mikro frontend, on jest web-komponentem i renderuje sobie w środku swojego reacta i one są po prostu udostępniane jako web komponenty. Nie ma, na poziomie kodu, to tam nie ma żadnych zależności. Wszystko to jest po prostu web komponent który renderuje, w naszym przypadku, np. profil użytkownika, np. wiadomości w czacie.

Bartek Witczak

Tak, tak jest.

Marek Piechut

I to jest web komponent. Jak chcesz mieć w swoim frontendzie czat, to renderujesz web komponent, mówisz tam kto z kim jak tam coś tam, w atrybutach tego web komponentu i on się renderuje.

Bartek Witczak

Dlatego suma sumarą moglibyśmy pójść w różne technologie. No bo każdy z tych komponentów to jest po prostu web komponent.

Marek Piechut

On jest web komponentem i współczesna przeglądarka każda go umie wyrenderować, także to jest w ten sposób u nas rozwiązane. I poszliśmy też tak, że te projekty są też całkowicie osobno budowane. Wzięliśmy sobie ESBuilda bo jesteśmy fancy itd, ale generalnie on bardzo dużo zmienił. Ze względu na to że nasz build time zrobił się bardzo szybki, to dawało się z tym pracować. Z tym że masz te 5, 6, 10, 15 modułów, które ciągle się tam budują, przebudowują w trakcie developmentu, to przy ESBuildzie nie jest żaden problem.

Bartek Witczak

I tylko żebyśmy to podkreślili. Prawdopodobnie to nie jest tylko zaleta tego, że to jest ESBuild. To jest zaleta tego że jest EBIT, ale ten performance improvement bierze się w dużej mierze z tego, że teraz sprawdzanie typów testowych nie jest częścią budowania. Czyli jakby ESBuild odpowiada tylko i wyłącznie za budowanie. Natomiast verify na poziomie typów jest odpalany po prostu jako część już potem pusha.

Marek Piechut

No tak, tylko wyrzuca typy. On tylko ma logikę która ignoruje typ gdzieś.

Bartek Witczak

Tak, tak.

Bartek Witczak

Natomiast sprawdził nam się i sprawdza nam się bardzo fajnie. Jest tam kilka rzeczy, które musieliśmy sami dopisać ale na razie jesteśmy zadowoleni i nie wracamy do web pack.

Marek Piechut

No dobra Bartek to teraz tak z Twojej perspektywy powiedz, co Ty o tym myślisz ostatecznie. Czy to jest według Ciebie dobry ruch, czy nie. Jakie tam widzisz zalety w tym. Może zacznijmy od dobrych stron.

Bartek Witczak

No dobra to na pewno to co mi się podoba to jest wyizolowanie powiedzmy sobie domeny do komponentu, to to jest fajna rzecz. Tak. Czyli jeżeli weźmiemy sobie na tapet ten nasz profil użytkownika to jeżeli mamy web komponent od profilu użytkownika i w naszym przypadku też jest tak, że akurat ta część beckend’owa również jest osobna no to mamy taki kawałek kodu który jest odpowiedzialny tylko za tą jedną rzecz. Więc na plus na pewno zaliczyłbym to że jest takie powiedzmy sobie jakieś tam single responsibility principle.

Marek Piechut

Jest też najważniejsza kwestia w architekturze oprogramowania czyli rzeczy których nie chcesz żeby się działy muszą być trudne do zrobienia. Czyli przez to że mamy te rzeczy podzielone to jeżeli chciałbyś tam sięgać po to, to już nie jest proste. Dużo łatwiej będzie ci to nawet skopiować czy przerzucić do jakiejś biblioteki której użyjesz niż teraz tu jakieś robić kombinacje no bo te rzeczy się nie widzą i będziesz musiał tam kombinować żeby to gdzieś zrobić. Także to jest bardzo ważna rzecz. Bo jak wiemy to pisanie ogólnych zasad robienia projektu nigdy nie działa. To, że jest napisane że ten moduł nie będzie korzystał z tego to nie znaczy że on nie będzie.

Bartek Witczak

Albo stworzenie sobie struktury katalogów z jakimś indeksem który powinien eksportować publiczne rzeczy i nie sięganie do bebechów fajnie wygląda z perspektywy tego, że fajnie gdyby tak ludzie robili ale zawsze znajdzie się ochotnik który postanowi pogrzebać sobie w module.

Marek Piechut

Tym bardziej że tam VSCode i inne automaty ignorują to zupełnie, importują automatycznie.

Bartek Witczak

Dokładnie. Więc to na pewno jest duża zaleta czyli takie powiedzmy sobie takie twarde boundry. Tutaj ważne jest to, że jest to boundry żebyśmy nie sięgali do tych innych modułów. Ale biorąc pod uwagę to że my mamy mono repo i wszystko dzieje się w jednym projekcie to i tak mogą zdarzyć się sytuacje że jak ktoś sobie programuje control spacja to będzie importował rzeczy z innych modułów.

Marek Piechut

No tak ale to się nie zbundluje.

Bartek Witczak

To mu się nie zbundluje, ale wciąż może być tak.

Marek Piechut

Można spróbować.

Bartek Witczak

I potem jest taka sytuacja że możesz walczyć z tym że “no ale importuje jakąś sprawdzoną rzecz tutaj nie działa.” I wtedy zauważa że ” aha nie działa no bo to nie jest twój moduł”.

Marek Piechut

Import to są cztery razy dwie kropki i tak dalej.

Bartek Witczak

Więc to jest na pewno na plus. Druga rzecz to jest jakby konsekwencja tego. No to jeżeli my chcemy ten fragment użyć w innych projektach no to to jest po prostu użycie web komponentu.

Marek Piechut

Tak, to moim zdaniem też jakby bardzo dobrze wyszło że jakby okazało się że jeżeli dobrze sobie zaplanujemy web komponenty to te rzeczy są bardzo łatwo re-używalne. I to jest taka druga rzecz której za wszelką cenę nie chcieliśmy zrobić i nie zrobiliśmy chociaż są takie koncepcje to nie podzieliliśmy w żaden sposób, nie współdzielimy żadnego Redux-a, Store-ów, żadnych takich rzeczy pomiędzy tymi web komponentami pomiędzy tymi frontendami. I one muszą sobie albo dać radę przez backend albo przez event base. I to jest koniec. Mogą tylko eventy albo albo sobie gadać przez backend.

Bartek Witczak

Tak jest. Czyli jednym słowem one naprawdę są niezależne. Tam nie ma takiego implicit boundingu z jakimiś innymi modułami że wymagamy żeby coś innego istniało w systemie żeby zadziałał web komponent.

Marek Piechut

Mieliśmy przez jakiś czas nawet tak że część miała Redux’a a część miała i Recoil-a z którego zrezygnowaliśmy na koniec. To też jest dobry materiał na następny odcinek, dlaczego wychrzaniliśmy Rico. I te rzeczy sobie tam spokojnie współdziałały. Nie było żadnych problemów. Żadnych to też troszkę nadużycie no bo czasami trzeba było z tym walczyć ale utrzymaliśmy tą rzecz że tam rzeczy są całkowicie rozłączne nawet do tego stopnia że w development można było sobie jakby w swoim pustym HTML’u wsadzić web component jeden i sobie z nim pracować. I to wszystko działa i nie ma żadnych problemów że on tam wymaga czegoś dookoła.

Bartek Witczak

To jest w ogóle druga zaleta o której chciałem powiedzieć albo może trzecia czy kolejna po prostu. Czyli jeżeli mamy web komponent i to jest taki rzeczywiście osobny moduł to my sobie możemy spokojnie go rozwijać w ogóle niezależnie od reszty powiedzmy systemu. Tak. To też wynika z tego jak my to sobie pokazaliśmy ale summa sumarą mogliśmy zrobić tak żeby pracować tylko i wyłącznie na tym web komponencie. Czyli nie potrzebowaliśmy podnieść całej aplikacji i w ogóle całego naszego tego bałaganu żeby móc pracować nad jakimś jednym web komponentem.

Marek Piechut

I to jeszcze może być tak że ten web komponent np. korzysta tylko z jednego backendu więc znowu nie musisz całego środowiska stawiać sobie gdzieś tam tylko masz ten jeden twój backend pracujesz, pracujesz potem to integrujesz i tak dalej i to nawet nawet się sprawdzało.

Bartek Witczak

No dobra jakie jeszcze zalety.

Marek Piechut

Zalety inne. To jest ciekawe pytanie. Wiesz to takie standardowe zalety. Zalety web komponentów cały czas wchodzą w grę czyli nic nie przeszkadza żebyśmy te rzeczy teraz rozdzielali do osobnych repozytoriów i żeby ktoś tam w ogóle inny to robił. W pewnym sensie też nie do końca no bo tam skończyliśmy z jakimś wspólnym modułem ale on mógłby być wyciągnięty do biblioteki.

Bartek Witczak

Tak, on mógł być naszą biblioteką.

Marek Piechut

Bo tam są takie rzeczy które są bardzo niezależne od projektu albo są takie naprawdę reużywalne i nie zależą od niczego. Także te rzeczy wchodzą w grę. To że mamy deployowalność osobną też wchodzi w grę chociaż to już moim zdaniem jest taka wątpliwa korzyść jeżeli chodzi o frontendy no bo tam nie ma większości tych problemów. No dobra też są bo możesz czekać na jakiś backend, a nie doczekać się tak że ktoś coś musi mieć na backendzie, ale nie może mieć więc nie może zdeployować nowej wersji. Więc cała reszta świata czeka. No to tutaj nie do końca musi być ten problem. Nie wiem mógłbyś spróbować całą apkę nowych wersjach bez jakiegoś modułu.

Bartek Witczak

Tak jest. Mogliśmy to zrobić spokojie. Powiedzmy sobie możemy to zaliczyć na poczet zalet ale to pewnie powinno zostać wyeliminowane na etapie jakiegoś tam deploymentu czy testingu. Jeżeli nie będzie działał web komponent to cała aplikacja dalej działa.

Marek Piechut

Tak, jak się nawet nie załaduje. W sensie że nawet kiedy tam nie działa ten serwer, który to serwuje czy coś, to po prostu wszystko dalej śmiga.

Bartek Witczak

I to wbrew pozorom jest zaleta. Biorąc pod uwagę to że jeżeli będziemy korzystali z komponentu który nam łapie te błędy to przeważnie spotykamy się że w projektach jest takie jedno miejsce prawie przy samym Roocie które łapie błędy i wyświetla “Przykro nam ale popsóła się aplikacja.” No nie. Tutaj siłą rzeczy będziemy tych miejsc mieli wiele. Tak, bo prawdopodobnie każdy z web komponentów sam łapie takie miejsce i sam będzie wyświetlał. Spróbuj później.

Marek Piechut

Ta,k to jest jakby ten z tych klasycznych zalet web komponentów. Ja się powiem ci bałem bardzo tego żebyśmy zrobili te komponenty. Ale wyszło tak moim zdaniem całkiem spoko w sensie że nie licząc tych rzeczy o których zaraz też będziemy gadać to sprawdza sie całkiem nieźle.

Bartek Witczak

No dobra przejdźmy do tych problemów.

Marek Piechut

No według mnie duży ból cały czas jest taki że do końca ta infrastruktura jednak nie jest gotowa i web pack wiem że coś tam buduje ale w as buildzie nie ma nic. No i to też nie jest takie proste do rozwiązania że trzeba by troszkę się nad tym napracować i też będziemy trochę rozwiązywać ten problem. Mianowicie mamy bardzo dużą teraz duplikację kodu finalnego która jest parsowana w przeglądarce.

Bartek Witczak

Dokładnie.

Marek Piechut

Czyli mamy 5 reactów które renderujemy i dużo tego wszystkiego. No i oczywiście można by to ręcznie robić jako externalsy i tak dalej i tak dalej. No ale to jest upierdliwe. Pewnie zrobimy to do jakiegoś poziomu bo pewnie tam React i właśnie Lodash-a jakieś takie duże rzeczy które jakby duży zysk jest ale inwestycja niewielka to się opłaci. No niestety to jest ten ból.

Bartek Witczak

Tutaj wbrew pozorom takim najprostszym rozwiązaniem to jest tak jak mówisz externalsy czyli powrót do tego co działało 20 lat temu czyli po prostu import biblioteki. Tak. I to rozwiązałoby wszystkie problemy związane z duplikowaniem 14 reactów, 15 Lodash-y i 13 routerów. Potem by się okazało że to jest z cashowane z innej strony i w ogóle startup Time bardzo dawno temu się odpalił. Tak jest. Więc to jest w ogóle ciekawy problem który jakby no jest związany z tym o czym już kiedyś rozmawialiśmy czyli jest związany z tym problemem jak ten nowoczesny development wygląda.

Marek Piechut

Że on trochę psuje cały internet, że ze względu na to że masz takie duże bundle które są paczkami wszystkiego ściągasz Lodash-a tysiąc razy, każda strona ma tego samego loda ale tego ściągasz 1000 razy bo jest potrzeba bo akurat tu jest wgrzany w tym miejscu.

Bartek Witczak

No dobra jaki jeszcze problem mamy, bo ja mam jeszcze jeden taki ciekawy.

Marek Piechut

No dawaj ciekawy.

Bartek Witczak

Nawet to nie jest problem tylko nasza sytuacja z tym jednym komponentem była taka który na początku był publikowany. To jak większości projektów tak mi się wydaje. Na początku było “nie w tym drugim module co ten komponent wygląda zupełnie inaczej” bo on tam musi robić tylko jedną dziesiątą z tej funkcjonalności. Nie, my nie potrzebujemy tam tego całego komponentu więc spokojnie możemy to skopiować bo tam jest ograniczona ilość rzeczy z których będziemy korzystać. No i potem oczywiście okazuje się bardzo często że jednak potrzebujemy prawie tego samego komponentu więc już re-użycie kodu ma większy sens. Ale problem o którym chciałem powiedzieć to jest to, że mikro komponent wiąże się prawdopodobnie z jakąś domeną. Teraz przy takim podejściu że ślepo robimy te nasze web komponenty może być taka sytuacja że tak naprawdę my wydzielamy jakiś tam mikro-frontend, który jest odpowiedzialny np. za jakiś user profil a okazuje się że i tak musimy utrzymywać zupełnie osobny kod dla obu wersji. Czyli jakby suma sumarum powiedzmy że z tego modułu nie eksportujemy jednego web komponentu tylko eksportujemy dwa, trzy różne.

Marek Piechut

Tak mamy.

Bartek Witczak

I tak mamy. Dla każdej platformy jest co innego. No i teraz tak naprawdę trzeba się zastanowić jaki jest ten bilans zysków i strat. Czy np. akurat w przypadku user profilu no to mamy zupełnie zewnętrzne API. Tak. Nie korzystamy w sensie zewnętrzne do tych innych modułów czyli powiedzmy w module A i B i nie korzystamy z tego API od userów. Więc sytuacja jest w miarę czysta bo wtedy my nie musimy w obu modułach dodawać obsługi API etc. etc. Ale gdybyśmy mieli już jakąś taką sytuację że i tak korzystamy z jakiegoś API w jednym i drugim module to trzeba by się było zastanowić czy rzeczywiście jest sens wyciągania takiego osobnego web komponentu.

Marek Piechut

No tak. To też są te problemy że nagle okazuje się że musisz mieć więcej bibliotek jakichś, które możesz include’ować.

Bartek Witczak

No.

Marek Piechut

Bo teraz twój kod już nie jest jakby commonem ogólnym tylko musiałbyś mieć biblioteki które każdy tam moduł sobie zaciąga. To jest overhead jakiś tam pracy. Także też nie ma co się oszukiwać że to jest wszystko świetnie bo jest tam narzut pracy które musi zrobić. Te rzeczy które musieliśmy walczyć z routerem. U nas też są specyficzne wymagania bardzo jeżeli chodzi o projekt bo część aplikacji ma mieć routing część ma nie mieć routingu i to w dodatku część jakby aplikacji routuje się ze względu na rzeczy które przychodzą z backendu. Tam jest taki specyficzny wymóg że jak jesteś w jakimś tam miejscu w aplikacji to już to co ci się pojawia jest na podstawie eventów z backendu, a nie na podstawie tego że ty masz coś w routerze. Tak że musieliśmy zrobić swoją implementację historii dla routera która deleguje coś tam przesyła przez te web komponenty, różne dziwne rzeczy. To tam chwilę pracy zjadło, ale rozwiązaliśmy to i wszystko dobrze działa. No i jest ten standardowy też problem mikrofrontendów. Mi się wydaje że my się z nim trochę spotykamy. I to jest problem tego że jednak te aplikacje są rozłączne więc one nie dzielą za dużo kodu a np. styl aplikacji jest commonem. Tak. I po prostu mamy standardowe rzeczy że jakieś fragmenty UI są zduplikowane bo będą bo też nie wyciągasz wszystkiego od razu do wspólnych bibliotek. No i potem te UI się rozjeżdża i potem szukasz we wszystkich modułach gdzie to jest. “Dobra dobra tutaj to były takie boardery to teraz zmieniam wszędzie tak jak trzeba.” Tak.

Bartek Witczak

I nie byłoby to problemem gdybyśmy na przykład sobie wzięli jakąś taką standardową bibliotekę komponentów i po prostu ją zaimportowali. Ale to oczywiście wymagałoby tego że nasza aplikacja nie byłaby stuprocentowo customowa.

Marek Piechut

Chyba nigdy w sumie nie robiłem aplikacji która byłaby ze standardowych komponentów… Dobrze się zdarzało zaczynać ale to się bardzo szybko kończyło.

Bartek Witczak

No tak to prawda. To jest jeden z powodów dla którego praktycznie nigdy nie zaczynamy od standardowych komponentów tylko piszemy swoje.

Marek Piechut

Tak, tak jeżeli są designy to one są zawsze takie, że “mogłoby być, ale tu nie pasuje, to też nie pasuje, to zmieniamy”.

Bartek Witczak

Jeszcze jeden problem który przychodzi mi do głowy to jest, tak jak wspominaliśmy wcześniej, żeby te mikrofrontendy w ogóle miały sens to one muszą być powiedzmy że całkowicie wyizolowane. Tak. One muszą być osobnymi modułami. I teraz jeżeli nagle w wymaganiach okaże się że te komponenty mają ze sobą rozmawiać to one muszą rozmawiać po jakimś bus-ie. Więc dochodzi cały taki powiedzmy techniczny overhead komunikacji pomiędzy tymi rzeczami.

Marek Piechut

I jeżeli chcesz utrzymać to że one naprawdę są odrębne, a chcesz to utrzymać bo jeżeli tego nie utrzymujesz to nie masz mikrofrontendów. No to ten narzut pracy jest większy. Nie możesz czegoś w sobie wrzucić w Redux-a i zaczytać ani tym podobnych konstrukcji. Musisz robić jakiś event bus i rzeczy które gdzieś tam się przesyłają bądź przez system eventów z backendem gdzieś tam rzeczy robić.

Bartek Witczak

Ostatnią rzeczą która nie jest do końca problemem mikrofrontendów, tylko wyzwaniem to jest oczywiście odpowiednie podzielenie tego. Tak. Jeżeli mają być to osobne moduły i ta komunikacja jest utrudniona to bardzo dobrze. Musimy sobie zdefiniować co jest takim mikrofrontendem i dlaczego akurat to. Czyli żeby te boundries-y nie były ani za małe ani za duże żeby to potem nie przeszkadzało w pracy.

Bartek Witczak

Muszą być we właściwym miejscu żebyś nie miał dużo potem cross-boundry roboty. Że trzeba troszkę rozeznanie w domenie złapać żeby te rzeczy ciąć, żeby nie było problemów na tych granicach.

Bartek Witczak

No dobra podsumowując to wszystko jaki dałbyś werdykt dla mokrofrontendów.

Marek Piechut

Zaskakująco nie wiem czy nawet nie nagraliśmy takiego odcinka w którym powiedziałem że to jest bez sensu.

Bartek Witczak

To jest bardzo możliwe.

Marek Piechut

To jest bardzo możliwe.

Bartek Witczak

Bardzo możliwe że był odcinek że mówiliśmy że coś jest bez sensu ale teraz uważamy że to jednak może nie być takie bez sensu.

Marek Piechut

Też nie powiedziałbym że to jest super rozwiązanie wszystkich problemów no bo jednak jest tego dosyć duży koszt ale bałem się większych perturbacji szczerze mówiąc, że jak przeszliśmy przez ten pierwszy etap że już rozsupłaliśmy sobie że chcemy to robić przez całe web komponenty. I zrobiliśmy już te wszystkie rzeczy że mamy wspólną część, która jest include’owana przez te wszystkie komponenty które są wspólne. I zrobiliśmy tą komunikację, jest ta szyna danych z backendem i tak dalej. To wszystko już sobie działa to okazuje się że to nie jest wcale aż taki duży problem jak się wydawało że będzie.

Bartek Witczak

A ja powiem taką wydaje mi się ciekawą rzecz. Gdyby nie było na początku tych dwóch modułów tylko byłoby to wszystko w jednym projekcie to prawdopodobnie nie mielibyśmy mikrofrontendów.

Marek Piechut

No nie mielibyśmy byśmy.

Bartek Witczak

Powiedzmy, byśmy sobie po prostu współdzielili kod. To też jest ta cecha że my już trochę sobie kodujemy i jakby powiedzmy że potrafimy zachować względnie dyscyplinę. Więc to nie byłby taki duży problem.

Marek Piechut

Potrafimy organicznie spaghetti ograniczać.

Bartek Witczak

Tak jest. No i wydaje mi się właśnie że gdyby tak było że na początku mielibyśmy po prostu jeden moduł jedną aplikację to to nadal byłaby jedna aplikacja i pewnie nie rozmawialibyśmy w ogóle na temat mikrofrontendów.

Marek Piechut

Tak. Tym bardziej, że jakby my mieliśmy faktycznie problemy z tym w sensie że jakby to był stan który musiał zostać, te aplikacje musiały być rozłączne i to coraz bardziej się namnażało. Także pojawiały się rzeczy które były pomiędzy nimi musiały się pojawiać i w jednej i w drugiej itd. I uznaliśmy że to w sumie może być najlepsze rozwiązanie. To też nie było tak, że w tym momencie mikrofrontendy są modne albo że są wygodne albo ładne albo pachnące. Więc my zrobimy mikrofrontendy. W sensie że jeżeli robilibyśmy jedną aplikację to pewnie nigdy by tam nie było żadnych mikrofrontendów i wcale byśmy tego nie żałowali.

Bartek Witczak

No i ja po prostu pozostałbym na tym stanowisku że wciąż nową aplikację którą startuje nie chce zaczynać od mikrofrontendów, chcę zaczynać jako jedną aplikację i jeżeli potrzebuję to zastanawiam się czy przejść do mikrofrontendów.

Marek Piechut

Ale ostatecznie nie wyszło źle.

Bartek Witczak

Ostatecznie ja jestem zadowolony. Dodaje się te elementy już teraz łatwo. Te problemy które mieliśmy to w dużej części sobie je ogarnęliśmy.

Marek Piechut

I okazało się też że ten wybór tych web komponentów jako jako tej warstwy łączącej wcale nie przez router czy tym podobne rzeczy czy ze wspólnym Redux-em gdzie tam niektórzy proponują takie rozwiązania które według mnie były złe. Ten wspólny reducks jest bardzo do odrzucenia w sensie że on. Nie. Po prostu nie.

Bartek Witczak

I tego zdania akurat nie zmienimy.

Marek Piechut

Przynajmniej do następnego odcinka. Także wyszło, że ostatecznie te pomysły były trafione. Nawet ten ESBuild w pewnym sensie jest trafionym pomysłem. To że te projekty budują się tak szybko i możesz mieć wszystkie odpalone naraz i to sobie wszystko śmiga. To myślę że też pomaga.

Bartek Witczak

Jeżeli nie boicie się ubrudzić sobie ręce w tym, że trzeba coś do AS bulid’a dopisać no to polecam.

Marek Piechut

Też bym nie przesadzał bo nie wszystko tam da się zrobić.

Bartek Witczak

Nie wszystko da się zrobić.

Marek Piechut

Jak ludzie mają określone jakieś potrzeby, no w web packu, wszystko co kiedykolwiek chciałeś jest napisane w web packu i po prostu bierzesz plug in do tego. A tutaj może być czasami bardzo pod górkę.

Bartek Witczak

Tak jest.

Marek Piechut

Polecamy spróbować. Jak ktoś ma problemy takie, że musi współdzielić jakieś komponenty między różnymi aplikacjami to polecamy.

Bartek Witczak

A ma więcej niż jeden moduł.

Marek Piechut

Tak jest.

Bartek Witczak

Nie robimy tego na siłę. Teraz nie budujemy wszędzie mikrofrontendów.

Marek Piechut

Ewentualnie jak pracujecie w Spotify i Maciej z 17 teamów frontendowych to też może być rozwiązanie waszych problemów. Będzie mniej meeting’ów może.