refactor: move big from n to arch

docs/architecture/05-micro-frontend.md

@@ -0,0 +1,118 @@
+---
+sidebar_position: 5
+---
+
+# 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. Производительность: Загрузка нескольких микрофронтендов может увеличить время загрузки приложения.
+
+🚀 **_Источник: DeepSeek_**