116 lines
9.4 KiB
Markdown
116 lines
9.4 KiB
Markdown
---
|
||
sidebar_position: 6
|
||
---
|
||
|
||
# Micro frontend
|
||
|
||
Микрофронтенды (Micro Frontends) — это архитектурный подход, который позволяет разделить фронтенд-приложение на независимые, слабо связанные части, каждая из которых может разрабатываться, тестироваться и развертываться отдельно. Этот подход вдохновлен микросервисной архитектурой и применяется для создания масштабируемых и поддерживаемых фронтенд-приложений.
|
||
|
||
Основные принципы разделения фронтенд-приложения на микрофронтенды:
|
||
|
||
## 1. Разделение по бизнес-возможностям (Business Capabilities):
|
||
- Каждый микрофронтенд должен отвечать за конкретную бизнес-возможность или функциональность (например, корзина покупок, профиль пользователя, каталог товаров).
|
||
- Это позволяет командам фокусироваться на своей области ответственности и независимо развивать свои части приложения.
|
||
|
||
**Пример:**
|
||
- Микрофронтенд "Каталог товаров" отвечает за отображение и фильтрацию товаров.
|
||
- Микрофронтенд "Корзина" отвечает за управление корзиной покупок.
|
||
|
||
## 2. Автономность (Autonomy):
|
||
- Каждый микрофронтенд должен быть независимым: разрабатываться, тестироваться и развертываться отдельно от других.
|
||
- Это позволяет командам работать независимо, не блокируя друг друга.
|
||
|
||
**Как достичь:**
|
||
- Использование отдельных репозиториев для каждого микрофронтенда.
|
||
- Независимые CI/CD-пайплайны для сборки и деплоя.
|
||
|
||
## 3. Изоляция (Isolation):
|
||
- Микрофронтенды должны быть изолированы друг от друга, чтобы изменения в одном микрофронтенде не влияли на другие.
|
||
- Это достигается за счет четких границ между частями приложения.
|
||
|
||
**Как достичь:**
|
||
- Использование iframe, Web Components или модульных систем (например, Module Federation в Webpack).
|
||
- Минимизация общих зависимостей между микрофронтендами.
|
||
|
||
## 4. Слабая связанность (Loose Coupling):
|
||
- Микрофронтенды должны взаимодействовать через четко определенные интерфейсы (API, события, сообщения).
|
||
- Это позволяет изменять внутреннюю реализацию одного микрофронтенда, не затрагивая другие.
|
||
|
||
**Пример:**
|
||
Микрофронтенд "Корзина" может подписываться на события от микрофронтенда "Каталог" (например, "товар добавлен в корзину").
|
||
|
||
## 5.Единый пользовательский интерфейс (Unified User Interface):
|
||
- Несмотря на разделение, приложение должно выглядеть и работать как единое целое.
|
||
- Это требует согласованности в дизайне, стилях и взаимодействии.
|
||
|
||
**Как достичь:**
|
||
- Использование общей библиотеки компонентов (например, Storybook).
|
||
- Согласованные стандарты стилей (например, CSS-in-JS, общие переменные).
|
||
|
||
## 6. Масштабируемость (Scalability):
|
||
- Архитектура должна поддерживать добавление новых микрофронтендов без значительных изменений в существующих частях.
|
||
- Это важно для больших команд и проектов, которые развиваются со временем.
|
||
|
||
**Как достичь:**
|
||
- Использование модульной системы (например, Webpack Module Federation).
|
||
- Четкие правила интеграции новых микрофронтендов.
|
||
|
||
## 7. Технологическая независимость (Technology Agnosticism):
|
||
- Разные микрофронтенды могут быть написаны на разных технологиях (React, Vue, Angular и т.д.).
|
||
- Это позволяет командам выбирать подходящие инструменты для своих задач.
|
||
|
||
**Пример:**
|
||
- Микрофронтенд "Каталог" написан на React.
|
||
- Микрофронтенд "Корзина" написан на Vue.
|
||
|
||
## 8. Совместное использование ресурсов (Shared Resources):
|
||
- Общие ресурсы (например, библиотеки, стили, утилиты) должны быть вынесены в отдельные модули или пакеты.
|
||
- Это помогает избежать дублирования кода.
|
||
|
||
**Как достичь:**
|
||
- Создание общей библиотеки компонентов.
|
||
- Использование монорепозиториев (например, Nx, Lerna) для управления общими зависимостями.
|
||
|
||
## 9. Маршрутизация (Routing):
|
||
- Маршрутизация между микрофронтендами должна быть четко организована.
|
||
- Это может быть реализовано как на уровне клиента (например, с помощью React Router), так и на уровне сервера (например, с помощью Nginx).
|
||
|
||
**Пример:**
|
||
- Маршрут /catalog загружает микрофронтенд "Каталог".
|
||
- Маршрут /cart загружает микрофронтенд "Корзина".
|
||
|
||
## 10. Безопасность (Security):
|
||
- Каждый микрофронтенд должен быть защищен от несанкционированного доступа.
|
||
- Это особенно важно, если микрофронтенды взаимодействуют с разными API или сервисами.
|
||
|
||
**Как достичь:**
|
||
- Использование CORS, JWT-токенов и других механизмов безопасности.
|
||
- Изоляция данных между микрофронтендами.
|
||
|
||
## Пример архитектуры микрофронтендов:
|
||
1. **Микрофронтенд "Каталог":**
|
||
- Отвечает за отображение товаров и фильтров.
|
||
- Написан на React.
|
||
- Взаимодействует с API каталога.
|
||
2. **Микрофронтенд "Корзина":**
|
||
- Отвечает за управление корзиной покупок.
|
||
- Написан на Vue.
|
||
- Взаимодействует с API корзины.
|
||
3. **Микрофронтенд "Профиль":**
|
||
- Отвечает за управление профилем пользователя.
|
||
- Написан на Angular.
|
||
- Взаимодействует с API профиля.
|
||
4. **Общая библиотека компонентов:**
|
||
- Содержит общие UI-компоненты (кнопки, формы, заголовки).
|
||
- Используется всеми микрофронтендами.
|
||
|
||
## Преимущества микрофронтендов:
|
||
1. Независимость команд: Команды могут работать над своими частями приложения, не блокируя друг друга.
|
||
2. Гибкость в выборе технологий: Каждая команда может использовать подходящие для её задач технологии.
|
||
3. Масштабируемость: Легко добавлять новые функции или микрофронтенды.
|
||
4. Упрощение поддержки: Меньшие и более простые части кода легче поддерживать.
|
||
|
||
## Недостатки микрофронтендов:
|
||
1. Сложность интеграции: Требуется четкая организация взаимодействия между микрофронтендами.
|
||
2. Дублирование кода: Возможно дублирование общих ресурсов, если они не вынесены в отдельные модули.
|
||
3. Производительность: Загрузка нескольких микрофронтендов может увеличить время загрузки приложения. |