Координация 4+ фронтенд-команд в одном монолите — это блокирующие рефакторинги каждые 2 месяца, merge conflicts и полуторадневные деплои. Мы разрабатываем микрофронтендную архитектуру — подход, при котором каждое бизнес-доменное приложение (каталог, корзина, оформление заказа) становится независимым модулем. Такая микрофронтенд архитектура ускоряет выпуск фич в 2–3 раза, снижает стоимость поддержки на 30% и позволяет командам выбирать свой стек (React, Vue, Angular). Опыт наших инженеров — 10+ лет, более 50 внедрений.
Почему микрофронтенды? Основные проблемы, которые мы решаем
Координация 4+ команд в монолите приводит к блокирующим рефакторингам и ожиданию деплоя. Каждая команда хочет развиваться в своём темпе, но общий код создаёт конфликты. Микрофронтенды решают эти проблемы: дают независимость деплоя, изоляцию ошибок и свободу выбора стека. Например, падение модуля каталога не блокирует корзину — Error Boundary обеспечивает graceful degradation.
Как микрофронтенды ускоряют разработку?
Параллельная работа команд и независимый деплой сокращают цикл поставки фич с недель до дней. В одном из проектов с 5 командами время выкатки уменьшилось с 3 дней до 6 часов. Это стало возможным благодаря изоляции изменений и автоматизации CI/CD.
Интеграционные подходы — сравнение
| Подход | 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/mf-config \ -H "Authorization: Bearer $DEPLOY_TOKEN" \ -d '{"catalog": "https://catalog.example.com/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 микрофронтендов. Дальнейшее масштабирование — в рамках отдельных задач. Стоимость рассчитывается индивидуально. Закажите разработку микрофронтендной архитектуры, чтобы ускорить выпуск фич и снизить стоимость поддержки. Свяжитесь с нами для консультации.