Frontend Architecture

Micro Frontends

Mikrousługi rewolucjonizowały backendy. Micro Frontends przynoszą to samo do frontendu — niezależne deploymenty, autonomia teamów i technologiczna wolność per domenę biznesową.

Module Federation

Technika #1

Webpack 5 / Vite

Lider rynku

Niezależny deploy

Zalety

ThoughtWorks 2019

Adopt od

5 technik implementacji Micro Frontends

Nie ma jednego sposobu na Micro Frontends — wybór zależy od wymagań izolacji, SSR i wielkości ekosystemu.

Podejście	Technika	Izolacja	SSR	Popularność
Module Federation	Webpack 5 / Vite	JS (shared if configured)	Partial	Bardzo wysoka
Single-SPA	Framework orchestrator	JS (soft)	Partial	Wysoka
Web Components	Custom Elements API	Shadow DOM (CSS)	Trudny	Średnia
Server-Side Composition	Nginx / Edge / Tailor	Pełna (oddzielne serwery)	Natywny	Niszowa (ale rośnie)
iFrame	Native browser iframe	Pełna	Nie	Niska (legacy)

6 wyzwań Micro Frontends i rozwiązania

Micro Frontends przynoszą overhead organizacyjny i techniczny — każde wyzwanie ma jednak sprawdzone rozwiązanie.

Shared State

Jak MF-y współdzielą dane (koszyk, auth)?

Custom Events, Shared Store przez MF, URL state, BFF

Design System

Spójny wygląd między MF różnych teamów

Design Tokens (CSS vars), Shared DS przez npm lub MF

Routing

Nawigacja między micro frontends

Single-SPA router, Module Federation + React Router

Bundle Size

Każdy MF duplikuje React/Vue

Module Federation shared: { react: { singleton: true } }

TypeScript

Types dla remote MF

Federation Plugin typings, @module-federation/typescript

Testing

E2E testing przez granice MF

Playwright + contract testing, Storybook integration tests

Często zadawane pytania

Co to są Micro Frontends i kiedy ich używać?

Micro Frontends to architektura frontend która rozkłada monolityczny frontend na mniejsze, niezależne aplikacje (micro frontends) które mogą być budowane, deployowane i utrzymywane przez różne zespoły niezależnie. Analogia do mikrousług: tak jak mikrousługi rozkładają monolity backendowe, micro frontends robią to samo dla frontendu. Główne zalety: Niezależne deploymenty — team A deployuje swoją część bez czekania na team B. Technologiczna niezależność — jeden MF może używać React, inny Vue. Skalowanie organizacyjne — każdy team posiada swój obszar UI end-to-end. Kiedy warto: duże zespoły (15+ frontend developers). Wiele niezależnych domen biznesowych w jednym produkcie (ecommerce: catalog + checkout + account). Legacy migration — stopniowo zastępuj stary monolityczny frontend nowymi MF. Kiedy NIE warto: mały zespół (1-5 osób). Prosta aplikacja. Overhead zarządzania MF nie jest wart przy małej skali. Problemy do rozwiązania: shared state (jak team A wie o loginie z team B?). Shared UI (design system). Performance (bundle size — każdy MF może duplikować React). Security (cross-origin, iframes). Routing (jak nawigacja między MF). Pionierzy: Spotify (backend for frontend), IKEA, Zalando, ThoughtWorks Tech Radar: Micro Frontends jako 'Adopt' od 2019.

Jak implementować Micro Frontends — techniki i podejścia?

Implementacje Micro Frontends: 1. iFrame-based: najprostszy — każdy MF jest osobnym iframe. Izolacja CSS i JS — zero konfliktów. Wady: słabe UX (scrolling, routing), security restrictions, SEO problemy. Dziś rzadko używany. 2. Web Components: każdy MF eksportuje Web Component (Custom Elements). Framework-agnostic — działa z React, Vue, Angular, Vanilla. Narzędzia: Lit (Google), Stencil. Problem: performance, server-side rendering. 3. Module Federation (Webpack 5): dynamiczne ładowanie komponentów z innego deploy-owanego bundla. 'Remote' MF eksportuje komponenty, 'Host' importuje w runtime. Jedna z najpopularniejszych technik. Szczegóły poniżej. 4. Import Maps: natywna przeglądarkowa specyfikacja dla mapowania nazw modułów na URL-e. Pozwala na lazy loading MF z różnych URL-ów. Narzędzia: systemjs, importmap-manager. 5. Server-Side Composition: serwer (np. Nginx, CDN Edge, Tailor.js) kompiluje HTML z różnych MF przed wysłaniem do przeglądarki. Najlepsza wydajność i SEO. Złożona implementacja. 6. Single-SPA: framework do orchestracji wielu SPA na jednej stronie. Router który aktywuje/deaktywuje micro apps. Bardzo popularne, dużo toolingu.

Module Federation — jak działa w praktyce?

Module Federation (Webpack 5): Module Federation pozwala jednemu build-owi ('Remote') eksportować moduły które inny build ('Host') może dynamicznie importować w runtime. Oba buildy są deployowane niezależnie. Jak działa: Remote application konfiguruje exposes w webpack config: exposes: { './Button': './src/components/Button', './Header': './src/components/Header' }. Host application konfiguruje remotes: remotes: { mfApp1: 'mfApp1@https://app1.example.com/remoteEntry.js' }. Host importuje dynamicznie: import('mfApp1/Button') → przeglądarka lazy-load'uje remoteEntry.js z app1.example.com. Shared dependencies: oba buildy mogą dzielić React (zamiast duplikować). shared: { react: { singleton: true, requiredVersion: '^18.0.0' } }. Narzędzia: Native Federation (Angular), Vite Module Federation plugin (vite-plugin-federation), rspack (szybszy Webpack compatible bundler). Wyzwania: version mismatch shared deps. Runtime errors gdy remote jest down. TypeScript types — potrzebujesz Federation Plugin dla types. Nowa generacja: Vite + vite-plugin-federation to coraz popularniejsza alternatywa dla Webpack Module Federation (szybszy DX). Module Federation Manifest — runtime discovery bez hardcoded URL-i.

Shared State i Design System w Micro Frontends?

Shared State w Micro Frontends: Największe wyzwanie — jak MF A wie o stanie (np. koszyk, logowanie) z MF B? Podejścia: Custom Events: MF emituje CustomEvent na window. Inne MF nasłuchują. Prosta implementacja, słaba type safety. Web Storage (localStorage/sessionStorage): prosty shared state przez storage. Risk: MF mogą sobie nadpisywać dane. Shared State Library przez Module Federation: jeden 'shared' bundle eksportuje Redux store lub Zustand store. Wszystkie MF importują shared. Problem: tight coupling. URL jako source of truth: URL parametry jako primary state. Dobry dla routing state. Backend for Frontend (BFF): dedykowany backend agreguje stan z różnych serwisów. MF pobierają stan przez API. Design System w Micro Frontends: Kluczowe: wszystkie MF muszą wyglądać spójnie. Podejścia: Shared Design System as npm package: design system publikowany jako pakiet npm. Każdy MF instaluje daną wersję. Risk: różne wersje = różne wyglądy. Design Tokens: CSS custom properties (variables) jako source of truth dla kolorów, typografii, spacingu. Każdy MF stosuje te same tokeny. Design System via Module Federation: design system eksportuje przez MF / Module Federation. Wszystkie MF ładują zawsze aktualną wersję z jednego URL. Storybook: dokumentacja i testowanie komponentów design system. Chromatic: visual testing dla design system.

Micro Frontends — performance i SEO wyzwania?

Performance w Micro Frontends: Główne ryzyka performance: Bundle size — jeśli każdy MF bundluje React osobno → przeglądarka ładuje React wiele razy. Rozwiązanie: Module Federation shared: { react: { singleton: true } }. Network waterfalls — jeśli MF-y ładują się sekwencyjnie. Rozwiązanie: preload hints, parallel loading. Hydration complexity — jeśli SSR + client-side MF. SEO w Micro Frontends: Problem: client-side MF są niewidoczne dla crawlerów bez JavaScript. Rozwiązania: Server-Side Composition (najlepsza SEO). SSR per MF (Next.js, Nuxt per team). Pre-rendering / Snapshots. Micro Frontends Performance Checklist: Shared dependencies (Module Federation shared). Lazy loading (ładuj MF gdy potrzebne, nie wszystkie na starcie). Pre-fetching critical MF. CDN per MF dla fast asset delivery. HTTP/2 push lub Early Hints. Measuring: Real User Monitoring (RUM) per MF — który MF spowalnia stronę? Web Vitals per MF (LCP, FID/INP, CLS). Lighthouse per route. Narzędzia: Webpack Bundle Analyzer, Statoscope. Lekcje z produkcji: Zalando migrował do micro frontends i raportuje 40% redukcję time-to-market. Ale piszą też o overhead koordynacji — nie jest bezkosztowe.

Czytaj dalej