Термин микрофронтенд ещё не стал столь общим местом, как термин «веб-приложение». Однако код внешних интерфейсов нередко не только исчисляется сотнями килобайт, но и крайне запутан.
Напрашивается аналогия. В бекэнд-технологиях микросервисный подход хорошо сработал и широко используется для структурирования независимых приложений. Почему бы не использовать этот подход к фронтенд-разработке?
Монолитный подход
Для написания веб-приложения мы обычно выбираем фреймворк: React, Vue, Angular, Svelte или другой. Фреймворки предоставляют простые решения для создания слоев модели, представления и контроллеров.
Весь код счастливо живет в одном большом хранилище. Время идет, люди приходят и уходят, рождаются и растут новые технологии. Происходит следующее:
- Становится всё труднее менять технический стек интерфейса. Приходится использовать что есть.
- Вновь пришедшим людям всё труднее понять код из-за его размеров и разнородности.
- Изменение небольшой части требует повторно развернуть и протестировать всё приложение.
Как разбить большое приложение на несколько независимых?
Тренд на микрофронтенды
Термин micro frontend блуждает в интернете в 2015 г., а активно стал обсуждаться с 2018 г.
Идея микрофронтенда базируется на том же принципе, что и микросервисы в бэкэнде. Каждое приложение существует независимо и имеет четко определенную цель.
Представим простой пример: электронная коммерция. Одно монолитное приложение может быть разбито на следующие микрофронтенды:
- Домашняя страница для отображения рекомендованных продуктов
- Страница корзины
- Страница оформления заказа
- Страница оплаты
Когда мы разделили задачу на микросервисы, мы можем разделить и ответственность членов команды, а также легче интегрировать соответствующие команды с такими же командами для бекенд-микросервисов.
Преимущества
- Легко изменить технический стек, брать на вооружение новые технологии.
- Каждое приложение независимо от других, будет содержать меньше кода и не будет мешать другим приложениям
- Быстрое обслуживание: поскольку у каждого приложения своя проблема, ошибку легко обнаружить и исправить.
- Быстрое развертывание: создавать и развертывать небольшие приложения проще и быстрее.
- Простое масштабирование: у каждого приложения свои требования к масштабированию, поэтому мы можем легко создавать разные среды.
Недостатки
- Особое внимание следует уделять общим библиотекам, используемым приложениями, чтобы браузер не загружал одну и ту же библиотеку несколько раз.
- Избыточность кода: некоторый код может повторяться в каждом приложении. Конечно, можно было бы написать вспомогательное приложение, которое будут использовать другие, но это создаст слишком тесную связь между ними.
- Архитектурная сложность: управлять монолитом проще, чем несколькими приложениями.
