ФГИСЛК

1. ФГИСЛК: Архитектура пользовательского интерфейса

2. Module Federation

3. Module Federation

Module Federation – плагин Webpack 5, позволяющий импортировать в
себя другое приложение, собранное Webpack в runtime. Иначе говоря,
этот плагин позволяет строить приложения-микрофронтенды.
Микрофронтенды – архитектурный паттерн, в котором независимо
доставляемые клиентские компоненты в браузер объединяются в единое
целое.
Подробнее:
Революция в микрофронтендах
Module Federation в Webpack 5
Как готовить микрофронтенды в Webpack 5
Module Federation: простая загрузка динамических модулей
Мой опыт с Webpack 5 Module Federation
Как готовить production с Webpack 5 module federation (HolyJS, видео)
Module Federation

4. Module Federation

Технические преимущества микрофронтендов с Module Federation:
-
Параллельная независимая разработка
-
Микрофронт может работать как независимая единица
-
Можно использовать любой фреймворк (с оговорками) и стек
-
Распространение библиотек между фронтами на клиенте
-
Экономия сетевого трафика
-
Потенциально быстрее отрисовка независимых частей
-
Переиспользование сервисов и информации из оркестратора
Недостатки:
-
Привязка к конкретному сборщику
-
Может потребоваться разработка оркестратора в зависимости от
реалий проекта
-
Требуется подготовка shared-библиотек внутреннего пользования
Module Federation

5. Module Federation

Бизнес преимущества микрофронтендов с Module Federation:
-
Экономия времени на разработку в распределенных командах
-
Экономия времени и ресурсов на CI/CD в части поставки
микрофронтов
-
Потенциальная возможность переиспользования готовых
компонентов, если они предполагают
-
Команды разработки независимы, разработку можно передать как
внутренним, так и внешним подрядчикам
-
Команды не тратят время на техническую интеграцию решений
других команд (с оговорками)
-
Составные части frontend могут находиться на любом хостинге
Module Federation

6. «Чистая» архитектура и Предметно-ориентированная архитектура

7. Внутренняя архитектура приложения

«Чистая» и «Предметноориентированная»
архитектура

8. Внутренняя архитектура приложения

Преимущества:
-
Гибкое масштабирование
-
Изолированность логики друг от друга, общение через интерфейсы
-
Логика зависит от бизнес-домена, а не наоборот
-
Независимость UI от логики
-
Легко тестировать отдельные части
-
Логика и зависимости переиспользуемы и легко заменяемы
Недостатки:
-
Может привести к избыточности кода
-
Требует строго соблюдения стиля разработки
-
Подходит только для больших систем
«Чистая» и «Предметноориентированная»
архитектура

9. Почему стоит использовать предложенную архитектуру

1)
Команды независимы друг от друга
2)
Команды могут распространять части подсистем друг другу как на этапе разработке, так и в режиме реального времени
3)
Команды работают в едином пространстве и единых рамках. При необходимости, команды можно переводить на другие модули с наименьшим
порогом вхождения
4)
Команды реализуют только свои бизнес-задачи
5)
Затраты на новую разработку окупятся быстрее, чем на разбор костылей из готовых систем
6)
Микрофронтенды дополняют матричную модель доступа к подсистеме – пользователь без прав не может в принципе попасть из интерфейса в
недоступный модуль
7)
В идеале, любую подсистему можно будет исключить из доступа пользователю без ущерба остальным подсистемам
8)
Любую часть приложения можно заменить с наименее возможными затратами на адаптацию нового решения
9)
Логика не зависит от UI – в последствии можно полностью заменить интерфейс на любой другой
ЛИГА ЦИФРОВОЙ ЭКОНОМИКИ

10. Схемы взаимодействий

11. Работа с виджетами

Процесс разработки в классическом подходе:
Процесс разработки при виджете-микрофронте:
Работа с виджетами

12. Взаимодействие микрофронтов

Взаимодействие
микрофронтов

13. Процедура разработки

14. Процедура разработки

1) Для существующих подсистем – возможно, редизайн
2) Для подсистем, предоставляющих виджеты – адаптировать
виджеты к новым требованиям
3) Для подсистем, которые разрабатываются с 0 – разработка,
согласно новым требованиям

15. Требования к разработке

Технологический стек:
-
React (18)
-
React Router (v6)
-
Typesctipt
-
MobX
-
Inversify
-
Axios
-
Material UI (CSS-in-JS/Scss)
-
Webpack 5
Опциональные требования:
-
Unit-тестирование (Jest, React Testing Library)
-
Storybook

16. Требования к архитектуре приложений

Архитектурные требования
-
Module Federation
-
Clean Architecture
-
Domain Driven Design
-
Dependency Injection & Dependency Inversion
Более подробно требования изложены в Code Policy для Frontend
разработки

17. Организация разработки

1) Монорепозиторий с npm workspaces для подсистем, которые
разрабатываются с 0
2) Для существующих подсистем – зеркалирование репозиториев в
группу фронтенда в проекте
3) Для подсистем, предоставляющих виджеты – раздел shared в
монорепозитории
Подробнее о структуре репозитория - Code Policy