Micro frontend: kiedy pomaga, a kiedy szkodzi w e-commerce?
Modułowość brzmi kusząco – podzielisz frontend na niezależne części, zespoły pracują równolegle, wdrażasz częściej. W teorii micro frontend to spełnienie marzeń CTO. W praktyce bywa koszmarem, który kasuje konwersję i mnoży koszty.
Zbudowałem kilkanaście architektur frontendowych dla sklepów i platform SaaS. Widziałem case’y, gdzie micro frontend uratował projekt, ale też takie, gdzie zabił go w ciągu miesiąca. W tym artykule rozkładam na części pierwsze, kiedy ta technologia działa, a kiedy lepiej ją odłożyć na półkę.
1. Kiedy micro frontend faktycznie działa?
Zacznijmy od pozytywów – bo są realne. Micro frontend sprawdza się tam, gdzie masz:
- Różne zespoły odpowiedzialne za różne domeny (np. jeden robi płatności, drugi wyszukiwarkę, trzeci koszyk)
- Wysoką częstotliwość releasów – chcesz deployować kilka razy dziennie bez czekania na całość
- Potrzebę skalowania technologicznego – jedna część może być w React, inna w Vue, a trzecia w vanilla JS
Przykład: duży marketplace z setkami kategorii i niezależnymi zespołami produktowymi. Każdy zespół wdraża co tydzień, a micro frontend pozwala im działać bez blokowania się nawzajem. To działa – jeśli kontrolujesz rozmiar i zależności.
2. Gdzie zaczyna się problem?
Tu robi się ciekawie. Micro frontend w e-commerce często staje się kulą u nogi. Dlaczego? Bo dodajesz abstrakcje, które:
- Zwiększają objętość JS – każdy mikrofrontend ciągnie swoje biblioteki, style, czasem nawet framework. Ludzie zapominają, że przeglądarka i tak musi pobrać wszystkie fragmenty. Kończysz z bundle’m, który waży 2 MB zamiast 500 KB.
- Tworzą zapętlenie w komunikacji – gdy jeden mikrofrontend musi porozmawiać z drugim (np. dodanie do koszyka ma odświeżyć ekwipunek), często lądujesz w bagnie eventów globalnych albo shared state’u, który jest gorszy niż monolit.
- Generują opóźnienia w UX – każde przełączanie między mikrofrontendami może powodować miganie, oczekiwanie na lazy loading, a w efekcie użytkownik czuje, że strona jest „szarpana”. Konwersja spada, a Ty nie wiesz, co jest winne.
3. Trzy sygnały, że powinieneś zrezygnować
Sygnał 1: Twój zespół nie radzi sobie z integracją
Jeśli wasze mikrofrontendy komunikują się przez globalne eventy albo ad-hoc przez window – to znak, że nie macie architektury, tylko chaos. W e-commerce, gdzie płatności, koszyk i podsumowanie muszą być idealnie zsynchronizowane, chaotyczna komunikacja to proszenie się o błędy w zamówieniach.
Sygnał 2: Performance spada, a Ty nie możesz tego zdebugować
Standardowy monolit masz jedną wiązkę JS – jeden profil, jedna odpowiedzialność. Przy micro frontendach narzędzia deweloperskie pokazują setki requestów, nie wiesz, który fragment odpowiada za opóźnienie. Testy wydajnościowe stają się koszmarem.
Sygnał 3: Masz mały zespół (do 5-6 osób)
Micro frontend to architektura dla organizacji, nie dla zespołów. Jeśli Twój zespół składa się z 3-4 osób, dzielenie frontendu na fragmenty skończy się większym nakładem na konfigurację, deploy i utrzymanie niż wartość dodana. Będziecie więcej czasu spędzać na budowaniu rusztowania niż na funkcjach biznesowych.
4. Alternatywa: monolit z dobrym podziałem
Zamiast pchać się w rozdrobnienie, wielu moich klientów wybiera monolit z modułową strukturą. To kompromis między szybkością rozwoju a prostotą: jeden deployment, jedna codebase, ale dobrze wydzielone foldery, komponenty i usługi. W e-commerce, gdzie całość jest ze sobą powiązana, monolit często wygrywa performance’em i łatwością debugowania.
Przykład: sklep odzieżowy z 50 tysiącami SKU. Zamiast robić osobny mikrofrontend dla kategorii i szczegółów, postawili na monolit z lazy loading dla rzadziej używanych widoków. Strona działa 3x szybciej, a zespół 5 osób realizuje zmiany w 2 dni, a nie tydzień.
Podsumowanie
Micro frontend to narzędzie, nie cel. Zanim go wdrożysz, zadaj sobie pytanie: czy Twój zespół jest na to gotowy? Czy Twoja aplikacja wymaga niezależnych fragmentów? A może zwykły monolit z modułami da Ci te same korzyści bez bólu głowy?
Jeśli masz więcej niż 6 osób w zespole frontendowym i wysoce niezależne domeny – micro frontend może być rozwiązaniem. Jeśli jesteś małym sklepem z 2 developerami – daruj sobie.
Uczę się na błędach innych. W JurskiTech często przepisujemy klientów z mikrofrontendów z powrotem na monolit – bo to się zwraca szybciej. A Ty? Znasz te bolączki?
