Micro-frontend: 3 b\u0142\u0119dy, kt\u00f3re dziel\u0105 Tw\u00f3j zesp\u00f3\u0142 i spowalniaj\u0105 wdro\u017cenia<\/p>\n
Rozmawiam z CTO \u015bredniej firmy produktowej. M\u00f3wi: \u201eWprowadzili\u015bmy mikrofrontendy, bo chcieli\u015bmy odblokowa\u0107 zespo\u0142y. Dzi\u015b mamy 5 repozytori\u00f3w, ka\u017cdy z w\u0142asnym frameworkiem, a deployment trwa d\u0142u\u017cej ni\u017c za monolitu\u201d. Brzmi znajomo?<\/p>\n
Micro-frontend sta\u0142 si\u0119 jednym z najmodniejszych trend\u00f3w architektonicznych ostatnich lat. Obietnica jest kusz\u0105ca: zespo\u0142y pracuj\u0105 niezale\u017cnie, technologie mo\u017cna dobiera\u0107 pod konkretny wid\u017cet, a skalowanie odbywa si\u0119 bez b\u00f3lu. W praktyce jednak wiele firm wpada w pu\u0142apki, kt\u00f3re odwracaj\u0105 korzy\u015bci.<\/p>\n
Jako technicy z JurskiTech.pl wdra\u017cali\u015bmy mikrofrontendy u kilkunastu klient\u00f3w \u2013 od startup\u00f3w po e-commerce z milionami u\u017cytkownik\u00f3w. Widzieli\u015bmy sukcesy i pora\u017cki. Oto trzy najpowa\u017cniejsze b\u0142\u0119dy, kt\u00f3re sprawiaj\u0105, \u017ce mikrofrontend zamiast pomaga\u0107 \u2013 dzieli zesp\u00f3\u0142 i spowalnia wdro\u017cenia.<\/p>\n
Micro-frontend to nie tylko technologia, to przede wszystkim decyzja organizacyjna. Najcz\u0119stszym b\u0142\u0119dem jest wycinanie kodu wzd\u0142u\u017c technicznych szw\u00f3w (np. \u201eheader osobno, stopka osobno\u201d) zamiast wzd\u0142u\u017c granic biznesowych.<\/p>\n
Przyk\u0142ad z \u017cycia: Klient e-commerce podzieli\u0142 aplikacj\u0119 na 4 mikrofrontendy: nawigacja, lista produkt\u00f3w, koszyk, p\u0142atno\u015bci. Ka\u017cdy zesp\u00f3\u0142 dosta\u0142 jeden kawa\u0142ek. Problem? Ka\u017cda zmiana w procesie zakupowym wymaga\u0142a koordynacji 4 zespo\u0142\u00f3w, bo logika przep\u0142ywu nie by\u0142a zamkni\u0119ta w jednym kontek\u015bcie. Deployment z tygodnia zszed\u0142 na miesi\u0105c.<\/p>\n
Co robi\u0107?<\/strong> Definiuj mikrofrontendy wed\u0142ug bounded context (DDD). Ka\u017cdy mikrofrontend powinien odpowiada\u0107 jednej funkcjonalno\u015bci biznesowej (np. \u201ezarz\u0105dzanie katalogiem produkt\u00f3w\u201d), a nie warstwie technicznej. Wtedy zmiana w katalogu nie wymaga dotykania koszyka.<\/p>\n Kiedy zespo\u0142y decyduj\u0105 si\u0119 na mikrofrontendy, pierwszym odruchem jest wrzucenie wszystkiego w iframe. Szybko, \u0142atwo, ale katastrofa dla UX: \u0142adowanie osobnych dokument\u00f3w, problemy z layoutem, brak p\u0142ynno\u015bci. Z drugiej strony, zbyt inteligentny \u201eshell\u201d (kontener) kt\u00f3ry zarz\u0105dza routingiem i stanem \u2013 cz\u0119sto staje si\u0119 nowym monolitem.<\/p>\n Pami\u0119tam przypadek z platform\u0105 SaaS, kt\u00f3ra zbudowa\u0142a shell z w\u0142asnym storem Redux, komunikacj\u0105 przez event bus i lazy loadingiem. Shell mia\u0142 200 kB JS po minifikacji \u2013 wi\u0119cej ni\u017c ca\u0142y monolit. \u0141adowanie strony wzros\u0142o o 40%.<\/p>\n Lepsze podej\u015bcie:<\/strong> Web Components jako technologia integracji. Ka\u017cdy mikrofrontend to niezale\u017cny web component, kt\u00f3ry komunikuje si\u0119 przez atrybuty i zdarzenia. Shell jest cienki \u2013 tylko inicjalizacja i routing po stronie serwera. Do komunikacji mi\u0119dzy mikrofrontendami u\u017cywaj dedykowanego event busa lub shared state (np. przez React Context, ale tylko dla danych globalnych jak u\u017cytkownik). Unikaj iframe, chyba \u017ce to naprawd\u0119 izolowana piaskownica.<\/p>\n W monolitycznym frontendzie deployment by\u0142 prosty: zbudowa\u0142e\u015b, wrzuci\u0142e\u015b na serwer. W mikrofrontendach ka\u017cdy zesp\u00f3\u0142 mo\u017ce deployowa\u0107 w\u0142asny kawa\u0142ek niezale\u017cnie. Brzmi pi\u0119knie, ale je\u015bli nie masz sp\u00f3jnej strategii wersjonowania i pipeline\u2019\u00f3w, szybko robi si\u0119 chaos.<\/p>\n Spotka\u0142em firm\u0119, gdzie ka\u017cdy zesp\u00f3\u0142 u\u017cywa\u0142 innego toolchainu: jeden Webpack, drugi Vite, trzeci Rollup. Efekt? Ka\u017cdy build produkowa\u0142 inne artefakty, a na produkcji miesza\u0142y si\u0119 wersje bibliotek. Raz w tygodniu co\u015b si\u0119 psu\u0142o, bo team A zaktualizowa\u0142 Reacta do 18, a team B zosta\u0142 na 17.<\/p>\n Rozwi\u0105zanie:<\/strong> Standaryzacja narz\u0119dzi i konwencji w ca\u0142ej organizacji. Wprowad\u017a shared CI\/CD z jednym pipeline\u2019em, kt\u00f3ry buduje ka\u017cdy mikrofrontend wed\u0142ug tego samego schematu. Ustal zasad\u0119 semver dla ka\u017cdego komponentu. Wykorzystaj narz\u0119dzia do monorepo (np. Nx, Turborepo) \u2013 wbrew pozorom monorepo \u015bwietnie dzia\u0142a z mikrofrontendami, bo zapewnia sp\u00f3jno\u015b\u0107 wersji i jeden system budowania, a jednocze\u015bnie pozwala na niezale\u017cne deploye.<\/p>\n Micro-frontend to jak ma\u0142\u017ce\u0144stwo: \u0142atwo wej\u015b\u0107, trudno utrzyma\u0107 harmoni\u0119. Klucz to nie technologia, ale granice organizacyjne, lekka integracja i solidny CI\/CD. Zanim rzucisz si\u0119 w wir dzielenia aplikacji, zadaj sobie pytanie: czy m\u00f3j monolit naprawd\u0119 boli? Cz\u0119sto odpowied\u017a brzmi: nie a\u017c tak bardzo.<\/p>\n Je\u015bli jednak decydujesz si\u0119 na mikrofrontendy \u2013 traktuj je jako narz\u0119dzie do skalowania zespo\u0142\u00f3w, nie tylko kodu. W JurskiTech.pl pomagamy firmom przej\u015b\u0107 t\u0119 transformacj\u0119 bez b\u00f3lu. Bo dobrze zaprojektowana architektura to nie tylko szybsze strony, ale i szybsze decyzje.<\/p>\n","protected":false},"excerpt":{"rendered":" Micro-frontend: 3 b\u0142\u0119dy, kt\u00f3re dziel\u0105 Tw\u00f3j zesp\u00f3\u0142 i spowalniaj\u0105 wdro\u017cenia Rozmawiam z CTO \u015bredniej firmy produktowej. M\u00f3wi: \u201eWprowadzili\u015bmy mikrofrontendy, bo chcieli\u015bmy odblokowa\u0107 zespo\u0142y. Dzi\u015b mamy 5 repozytori\u00f3w, ka\u017cdy z w\u0142asnym frameworkiem, a deployment trwa d\u0142u\u017cej ni\u017c za monolitu\u201d. Brzmi znajomo? Micro-frontend sta\u0142 si\u0119 jednym z najmodniejszych trend\u00f3w architektonicznych ostatnich lat. Obietnica jest kusz\u0105ca: zespo\u0142y pracuj\u0105<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[265,120,510,911],"class_list":["post-2883","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-frontendu","tag-ci-cd","tag-micro-frontend-2","tag-skalowanie-zespolu"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2883","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2883"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2883\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2883"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2883"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2883"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}B\u0142\u0105d #2: Integracja przez iframe lub zbyt ci\u0119\u017cki shell<\/h2>\n
B\u0142\u0105d #3: Ignorowanie CI\/CD i strategii wersjonowania<\/h2>\n
Podsumowanie<\/h2>\n