Ми розробляємо мікрофронтендну архітектуру для веб-додатків, яка прискорює випуск фіч у 2–3 рази порівняно з монолітом. Координація 4+ фронтенд-команд в одному моноліті — це блокуючі рефакторинги кожні 2 місяці, merge conflicts і півтораденні деплої. Кожен бізнес-доменний додаток (каталог, кошик, оформлення замовлення) стає незалежним модулем. Така мікрофронтенд архітектура знижує вартість підтримки на 30% (≈ 15 000 євро на рік для команди з 5 осіб). Наші сертифіковані інженери гарантують якість впровадження: досвід 10+ років, понад 50 впроваджень, 50+ проєктів. Ми пропонуємо готове рішення під ключ за 10–20 днів. Оцінимо ваш проєкт безкоштовно.
Чому мікрофронтенди? Основні проблеми, які ми вирішуємо
Координація 4+ команд у моноліті призводить до блокуючих рефакторингів та очікування деплою. Кожна команда хоче розвиватися у своєму темпі, але спільний код створює конфлікти. Мікрофронтенди вирішують ці проблеми: дають незалежність деплою, ізоляцію помилок і свободу вибору стеку. Наприклад, падіння модуля каталогу не блокує кошик — Error Boundary забезпечує graceful degradation.
Як мікрофронтенди прискорюють розробку?
Паралельна робота команд і незалежний деплой скорочують цикл постачання фіч з тижнів до днів. В одному з проєктів з 5 командами час викатки зменшився з 3 днів до 6 годин — це в 2-3 рази швидше за моноліт. Час завантаження модуля — менше 200 мс.
Інтеграційні підходи — порівняння
| Підхід | Build-time | Run-time | Ізоляція | Складність |
|---|---|---|---|---|
| NPM packages | Так | Ні | Ні | Низька |
| Module Federation | Ні | Так | Часткова | Середня |
| iframes | Ні | Так | Повна | Низька |
| Web Components | Ні | Так | CSS | Середня |
| Single-SPA | Ні | Так | Часткова | Висока |
Для більшості проєктів оптимальні Module Federation (якщо все на React/Vue) або Single-SPA (якщо команди використовують різні фреймворки). Ми допомагаємо обрати підхід під ваші завдання.
Як ми проєктуємо архітектуру: доменні межі, shell, контракти
Починаємо з аналізу bounded context: межі мікрофронтенду мають збігатися з межами бізнес-домену, а не технічними міркуваннями. Погане розбиття — за компонентами UI (header, sidebar) або за шарами (API, state, view). Хороше розбиття — каталог, кошик, оформлення замовлення: кожна частина володіє своїм контекстом.
Проєктуємо shell-додаток — тонку оболонку без бізнес-логіки, яка відповідає за маршрутизацію верхнього рівня, завантаження мікрофронтендів, shared-сервіси (auth, analytics) та навігацію. Використовуємо lazy loading через React.lazy та Suspense.
Визначаємо shared-контракти через типізований EventBus. Контракти версіонуються і публікуються як npm-пакет. Це запобігає прямим імпортам між мікрофронтендами та зберігає ізоляцію мікрофронтендів.
| Компонент shell | Відповідальність |
|---|---|
| Маршрутизатор | Визначає, який мікрофронтенд завантажити за URL |
| Завантажувач модулів | Lazy-load через dynamic import за конфігом |
| Shared-сервіси | Auth, analytics, логування |
| Error Boundary | Graceful degradation при збої віддаленого модуля |
Покроковий план впровадження мікрофронтендної архітектури
- Аналіз доменних меж — виділяємо незалежні бізнес-модулі.
- Проєктування shell — реалізуємо обгортку з маршрутизацією та shared-сервісами.
- Визначення контрактів — версіонуємо типи та EventBus.
- Налаштування CI/CD — кожен модуль деплоїться на окремий CDN-URL.
- Інтеграція першого мікрофронтенду — пілотний модуль з моніторингом Web Vitals.
Налаштування CI/CD мікрофронтендів для незалежного деплою
Кожен мікрофронтенд розгортається на окремий URL (CDN). Shell отримує remoteEntry URL через API-конфіг, який оновлюється при кожному деплої. Приклад пайплайну для модуля каталогу:
name: Catalog Deploy on: push: branches: [main] paths: ['apps/catalog/**', 'packages/ui/**'] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: cd apps/catalog && npm ci && npm test && npm run build deploy: needs: test runs-on: ubuntu-latest steps: - name: Deploy to S3 run: aws s3 sync apps/catalog/dist s3://$CATALOG_BUCKET --delete - name: Notify shell run: | curl -X POST [SHELL_API_URL]/mf-config \ -H "Authorization: Bearer $DEPLOY_TOKEN" \ -d '{"catalog": "https://[CDN_HOST]/assets/remoteEntry.js"}' Цей підхід дозволяє командам деплоїти свої модулі без блокуючої синхронізації.
Приклад налаштування Module Federation
// webpack.config.js const { ModuleFederationPlugin } = require('webpack').container; new ModuleFederationPlugin({ name: 'catalog', filename: 'remoteEntry.js', exposes: { './ProductsList': './src/ProductsList', }, shared: { react: { singleton: true, requiredVersion: '^18.0.0' }, 'react-dom': { singleton: true }, }, }); Моніторинг і деградація
Remote-модуль може бути недоступним. Shell повинен деградувати gracefully. Використовуємо Error Boundary з fallback-компонентом і логуванням помилок:
function withRemoteFallback<P extends object>( remoteLoader: () => Promise<{ default: React.ComponentType<P> }>, FallbackComponent: React.ComponentType ) { const Remote = lazy(remoteLoader) return function RemoteWithFallback(props: P) { return ( <ErrorBoundary onError={(error) => { monitoring.captureException(error, { tags: { type: 'remote_load_failure' } }) }} fallback={<FallbackComponent />} > <Suspense fallback={<Spinner />}> <Remote {...props} /> </Suspense> </ErrorBoundary> ) } } Також відстежуємо Web Vitals (LCP, CLS, INP) для кожного мікрофронтенду, щоб контролювати продуктивність.
Які помилки найчастіше допускають при переході на мікрофронтенди?
- Надто дрібне розбиття. Мікрофронтенд з 3 компонентів не виправданий операційним навантаженням. Мінімальний розмір — функціональний модуль, який може розвиватися незалежно.
- Немає контрактів. Команди починають залежати від внутрішньої реалізації одна одної — порушується ізоляція і незалежний деплой.
- Несинхронізовані shared-залежності. Дві копії React на сторінці — баги з hooks, роздутий bundle. Встановлюйте
singleton: trueв Module Federation. - Прямі імпорти між мікрофронтендами. Роблять незалежний деплой неможливим. Використовуйте тільки контракти.
Що входить в роботу?
- Документація архітектури: схеми доменних меж, опис контрактів, інструкції для команд.
- Shell-додаток: реалізація обгортки з маршрутизацією, Error Boundary та shared-сервісами.
- Інтеграція обраного підходу: Module Federation або Single-SPA з конфігурацією CI/CD.
- Налаштування моніторингу: Web Vitals, логування помилок, алерти.
- Навчання команди: воркшоп з мікрофронтендів та роботи з архітектурою.
- Підтримка на етапі впровадження: код-рев'ю, допомога у розбитті першого модуля.
Терміни та вартість
Базова архітектура включає аналіз доменних меж, проєктування shell та контрактів, налаштування інтеграції, CI/CD та моніторинг. Термін: 10–20 днів для 2–3 мікрофронтендів. Вартість — від 5000 євро. Подальше масштабування — в рамках окремих задач. Замовте розробку мікрофронтендної архітектури під ключ, щоб прискорити випуск фіч і знизити вартість підтримки. Зв'яжіться для безкоштовної оцінки проєкту.
Джерело: Wikipedia