4 of 20

Архитектура приложения

Для начала давайте рассмотрим стандартную архитектуру Front-End приложения. Она состоит из следующих частей:

Переиспользуемые компоненты — атомарные и более сложные, которые несут в себе бизнес логику которые мы используем для построения наших страниц;
Один общий store, который помогает нам обмениваться между компонентами, страницами и т. д., а также хранить информацию из базы данных;
Множество библиотек и, как следствие, большое количество зависимостей;

Собрать все эти части можно несколькими способами. Давайте рассмотрим каждый подробно.

5 of 20

Монолит

Монолитное приложение на фронтенде — это архитектурный подход, при котором весь пользовательский интерфейс (UI) и логика взаимодействия реализованы в рамках одного единого проекта. Вся структура — от компонентов до маршрутизации и состояния — находится в одном кодовом репозитории и разворачивается как единое целое. Основные характеристики монолитной архитектуры:

Единый кодовый репозиторий. Весь код — компоненты, стили, утилиты, роуты — хранятся в одном месте.
Один процесс сборки. Приложение собирается и деплоится как единый бандл.
Общие зависимости. Все части приложения используют одни и те же библиотеки и фреймворки.
Цельное состояние. Управление состоянием (например, через Redux или Context API) охватывает всё приложение.

6 of 20

Монолит. Преимущества

Простота разработки на начальном этапе. Быстрое прототипирование и запуск MVP
Общая структура. Возможность использования единого фреймворка
Единая точка входа. Легко настраивать CI/CD и легче тестировать

7 of 20

Монолит. Недостатки

Долгие сборки. С ростом нашего монолитного приложения время на CI/CD и на интеграционные тесты может вырасти с 10 минут до часу и даже больше
Сложность масштабирования. При росте приложения становится трудно управлять зависимостями и производительностью и соответственно у нас появляется высокая сложность понимания проекта для новых разработчиков
В монолите практически отсутствует изоляция. Все части приложения сильно зависят друг от друга — если что-то произойдёт с одной частью, то и другие тоже встанут
Сложность внедрения изменений в архитектуре монолита. Когда мы поменяли что-то одно в монолитной архитектуре, надо менять и другие части
Сложности с командной работой. Несколько команд, работающие над разными частями, могут мешать друг другу создавая конфликты в кодовой базе

8 of 20

Микросервисы

Микросервисы на фронтенде — это архитектурный подход, при котором пользовательский интерфейс разбивается на независимые, автономные модули, каждый из которых можно разрабатывать, тестировать, деплоить и масштабировать отдельно. Этот подход часто называют микрофронтендами (Micro Frontends), по аналогии с микросервисами на бэкенде. Основные характеристики микрофронтендной архитектуры:

Независимость. Каждый микрофронтенд может использовать свой стек технологий, фреймворк и процесс сборки
Изоляция. Модули не зависят друг от друга напрямую, что снижает риски при изменениях
Отдельный деплой. Можно обновлять части интерфейса без перекомпиляции всего приложения
Командная автономия. Команды работают над своими модулями без конфликтов с другими

9 of 20

Микросервисы. Преимущества

Независимость команд и технологий. Каждая команда может использовать свой стек: React, Vue, Angular — без необходимости согласовывать всё с другими командами. Таким образом можно постепенно переводить части приложения на новые технологии.
Отдельный деплой и сборка. Модули можно деплоить независимо, без пересборки всего приложения. Соответственно получаем более быстрые релизы
Масштабируемость. Легко добавлять новые фичи или команды, не затрагивая существующую архитектуру
Повторное использование компонентов. Один и тот же модуль (например, корзина или авторизация) можно использовать в разных сервисах
Изоляция ошибок. Ошибка в одном микрофронтенде не влияет на другие сервисы
Разделение ответственности. Команды фокусируются на бизнес-ценности своего модуля. Упрощается управление задачами, приоритезация и планирование

10 of 20

Микросервисы. Недостатки

Сложность инфраструктуры. Требуется продуманная система сборки, маршрутизации, интеграции и деплоя. Настройка CI/CD для каждого модуля может быть трудоемкой. Появляется необходимость в оркестраторе (например, Single-SPA, Module Federation), что добавляет уровень абстракции
Повышенные требования к согласованности. Разные команды могут использовать разные фреймворки, стили и подходы — это грозит фрагментированным UX. Необходимо внедрять дизайн-систему, общие UI-компоненты и гайдлайны, чтобы сохранить целостность интерфейса
Усложнение тестирования. Интеграционные тесты становятся сложнее: нужно проверять взаимодействие между модулями. Могут возникать баги на стыке микрофронтендов, особенно при обновлении одного из них
Проблемы с производительностью. При неправильной интеграции возможна избыточная загрузка ресурсов (дублирование библиотек, лишние запросы)

11 of 20

Module Federation: как работает и пример использования

12 of 20

Module Federation

Module Federation — это плагин, созданный изначально для webpack, который позволяет разделять код между несколькими независимыми приложениями и динамически загружать его в браузере пользователя. Это может быть полезно во многих случаях, когда необходимо создать масштабируемую архитектуру фронтенд-приложений.

Основные возможности Module Federation:

Динамический импорт модулей. Приложения могут загружать код друг друга без предварительной сборки.
Совместное использование зависимостей. Позволяет избежать дублирования библиотек и уменьшить размер сборки.
Изоляция и независимость. Каждый микрофронтенд может иметь собственный цикл релизов.
Поддержка разных сборщиков. Изначально построен для Webpack, но уже есть адаптации для Vite и других сборщиков

13 of 20

Module Federation. Host app

Теперь давайте рассмотрим пример конфигурации Module Federation на с использованием плагина vite-plugin-federation для сборщика Vite. Чтобы настроить Module Federation нам необходимо описать три основные конфигурации:

Хостового приложения (host) — приложение, которое загружает удаленные модули
Удаленного приложения (remote) — приложение, которое предоставляет модули
Shared зависимостей — список общих зависимостей, чтобы исключить многократную загрузку одинаковых пакетов

На скриншоте справа мы можем видеть пример конфигурации нашего host приложения. Мы указываем имя модуля, список удаленных модулей (remotes) которые мы хотим использовать в нашем хосте с url адресом по которому мы можем их получить, а также список общих зависимостей (shared).

С более тонкими возможностями настройками плагина можно ознакомится в документации

14 of 20

Module Federation. Remote app

В конфигурации удаленного приложения мы указываем:

Имя модуля
Имя файла с билдом модуля которые будет подгружаться в хост
Список компонентов (exposes), открытых для общего доступа из которых состоит удаленный модуль
Список общих зависимостей (shared)

Более подробно ознакомиться с кодом готового примера рабочего приложения построенного на ReactJS с помощью Vite и Module Federation вы можете перейдя по ссылке в GitHub репозиторий lastfm-micro-frontends

15 of 20

Выводы

16 of 20

Выводы

Микрофронтенд архитектура имеет смысл, когда недостатки монолита начинают преобладать над преимуществами. Например, когда вы сталкиваетесь с такими проблемами:

Есть несколько команд, которые делают одно дело и постоянно спотыкаются друг об друга, конфликтуют
Доставка до продакшена стала очень долгая и фичи реализуются с задержкой
Преимущества монолита становятся его недостатками

Во всех этих ситуациях стоит задуматься о микрофронтендах. В данной презентации мы рассмотрели подход построения микрофронтендов основанный на Module Federation. Это не единственный инструмент для построения микрофронтендов. Поэтому перед тем как реализовывать рекомендую изучить все имеющиеся инструменты и выбрать тот который лучше подходит под ваши требования.

1 of 20

2 of 20

3 of 20