Wstęp
Gdy słyszę „mikrofrontendy”, od razu wiem: ktoś oglądał konferencje Netflixa albo czytał case study Spotify. I super – te firmy mają zespoły liczące setki inżynierów, osobne zespoły odpowiedzialne za checkout, profil czy wyszukiwarkę. Ale Ty? Jeśli prowadzisz SaaS z 5-10 osobami w IT, mikrofrontendy mogą być najdroższym błędem architektonicznym, jaki popełnisz.
Nie mówię, że są złe. Mówię, że w złym kontekście niszczą budżet, spowalniają development i zabijają UX. A Ty nie masz czasu ani pieniędzy, by testować na sobie lekcji, które Netflix odrobił za miliony dolarów.
1. Koszt złożoności, który zabija tempo
Iluzja niezależności
Mikrofrontendy miały dać swobodę: każdy zespół rozwija swoją część, w swoim frameworku, własnym tempem. Tylko że w praktyce małe zespoły szybko odkrywają, że zamiast jednego repozytorium mają 5, zamiast jednego builda – 10, a zamiast jednej integracji z API – bałagan.
Pamiętam startup, który w 2022 postawił na mikrofrontendy. Było 3 developerów, a każdy pisał w innym frameworku: jeden w React, drugi w Vue, trzeci w Svelte. Po pół roku spędzali 40% czasu na uzgadnianiu, jak przesyłać dane między aplikacjami. Główny produkt – prosty panel analityczny – nie rósł, bo zespół ugrzązł w integracjach.
Kiedy podział ma sens?
Jeśli masz jeden zespół i jeden produkt, monolit frontendowy jest często szybszy i tańszy. Oszczędzasz na:
- konfiguracji (jeden bundler, jedna konfiguracja CI/CD)
- testach (mniej mockowania komunikacji między mikrofrontendami)
- wdrożeniach (jeden deployment zamiast koordynacji wielu)
Dla 80% SaaS mikrofrontendy to overengineering. Zyskujesz „niezależność”, ale płacisz za nią spowolnieniem.
2. UX cierpi, gdy frontend dzieli się na kawałki
Opóźnienia i szarpanie
Każdy mikrofrontend to osobny bundle JavaScript. Gdy użytkownik wchodzi na stronę, przeglądarka musi pobrać wiele paczek, a każda może mieć własne zależności. Efekt? Dłuższy czas ładowania, a na słabszych łączach – wrażenie, że strona „skacze” (tzw. layout shift).
W e-commerce to zabójca konwersji. Badania mówią, że każde 100 ms opóźnienia kosztuje 1% sprzedaży. Jeśli więc masz 5 mikrofrontendów na stronie produktu, a każdy dodaje 50 ms, tracisz klientów.
Niespójność interfejsu
Gdy każdy zespół ma swój własny komponent przycisku, dropdownu czy modala, szybko pojawiają się różnice. Jeden przycisk jest niebieski, drugi granatowy; jeden zaokrąglony, drugi prosty. Klient tego nie nazwie, ale czuje, że coś jest „nie tak”. A w e-commerce to spadek zaufania.
Prawdziwa historia: klientka narzekała, że w sklepie internetowym po dodaniu produktu do koszyka przycisk zmienia kolor – ale tylko na niektórych podstronach. To był efekt dwóch mikrofrontendów zarządzających komponentem koszyka. Zajęło 3 dni, by zunifikować wygląd, bo kod był rozrzucony.
3. Kiedy mikrofrontendy faktycznie pomagają?
Skala i zespół
Mikrofrontendy mają sens, gdy:
- pracuje nad aplikacją więcej niż 5-6 zespołów
- każdy zespół ma własne cele biznesowe (np. zespół płatności vs zespół wyszukiwarki)
- potrzebujesz niezależnego wdrażania (np. jedna część może być 24/7, inna w trakcie refactoringu)
Jeśli Twój zespół liczy 3-5 osób i lider mówi „chcę mikrofrontendy, bo to modne” – to znak, że warto poszukać prostszej architektury.
Alternatywy
Zamiast dzielić frontend na mikrofrontendy, rozważ:
- monolit z modularnym kodem (folder per feature, ale jeden build)
- monorepo z jednym frameworkiem (np. React + Nx)
- autonomiczne komponenty (prosty Web Components + wspólny design system)
Te rozwiązania dają 90% korzyści z mikrofrontendów (modułowość, łatwość utrzymania) przy 10% kosztów.
Podsumowanie
Mikrofrontendy to potężne narzędzie, ale nie dla każdego. Zanim je wdrożysz, zadaj sobie pytanie: czy Twój zespół jest gotowy na złożoność, którą przynoszą? Jeśli nie – wybierz prostsze rozwiązanie. Szybkość wdrożenia i niskie koszty utrzymania są ważniejsze niż „czysta” architektura. W JurskiTech widzieliśmy wiele firm, które przepaliły budżet na mikrofrontendy, by potem wracać do monolitu. Nie bądź jedną z nich.
