Я написал данный пост, так как чувствую, что Микрофронтенды это стало не просто модное слово, они уже начали распространятся на большие проекты.

Микрофронтенды могут быть следующей важной вехой в фронтенд разработке.

Давайте я вам расскажу почему!

Что такое микрофронтенды?

Микрофронтенды – это определенная структура архитектуры кода для фронтенд приложений. Все это берет начало из микросервисов на бэкенде.

Для понимания микрофронтендов и почему они нам нужны, в первую очередь нам необходимо узнать немного о них.

Микросервисная архитектура — вариант сервис-ориентированной архитектуры программного обеспечения, направленный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — микросервисов, получивший распространение в середине 2010-х годов в связи с развитием практик гибкой разработки и DevOps. (Википедия)

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

• Товары

• Категории товаров

• Отчеты

• Клиенты

• Заказы

Примечание: это упрощенный пример микросервисной архитектуры. В настоящем приложении мы могли бы иметь десятки, а то и сотни микросервисов.

В мире фронтенда, для такого типа приложения, мы могли бы разделить всё так:

Давайте отметим несколько вещей:

• Каждый микрофронтенд может быть построен с использованием различных технологий.

• За каждый микрофронтенд может отвечать отдельная команда.

• Каждый микрофронтенд может отвечать за один микросервис.

Почему стоит выбрать микрофронтенды?

Какие преимущества это может дать? На самом деле довольно много.

Помните те времена, когда вы устраиваетесь на работу, в которой разрабатывают уже старый проект, и фронт построен на XSLT и jQuery? Переписание проекта с нуля даже не рассматривается, и вам приходится использовать эти старые технологии для добавления нового функционала и исправления багов.

Если даже у вас вышло переубедить боссов начать переписывать проект, и у вас через 1-3 года появляется полностью переписанный проект. То, что мешает, через те же 10 лет, новым технологиям стать аналогом XSLT и jQuery, и морально устареть?

Микрофронтенды дают нам:

• Маленькую, более поддерживаемую кодовую базу.

• Отдельный микрофронтенд может быть написан с выбором технологий на любой вкус – что также позволяет убрать лишние зависимости.

• За микрофронтенд может отвечать отдельная команда – позволяет убрать взаимодействие между командами, что ведет к более быстрой разработке.

• Мы можем обновить, переписать или удалить микрофронтенд когда мы посчитаем нужным.

Со стороны бизнеса, правда, нужно будет взять некоторую дополнительную ответственность. Нужно будет постоянно заменять старые микро-(сервисы/фронтенды) на новые. Что позволяет постоянно улучшать свою кодовую базу.

Пример:
Мы можем удалить старый framework.X.js микрофронтенд и полностью заменить его новым framewok.Y.js. Это уменьшает необходимость переписывания, при необходимости, всего приложения с нуля.

Различные подходы

Есть несколько разных подходов в построении микрофронтендов.

Подход 1 – Один микрофронтенд на каждый микросервис

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

Подход 2 – Компоненты

В данное время многие UI фреймворки добавляют поддержку компонентов (Svelte очень хорош в этом).

Мы можем иметь старый UI и постоянно менять старый код на компоненты. Каждый новый компонент может быть микрофронтендом написанном на Svelte, Vue, vanilla JS, или чем-либо другом на ваш выбор.

Код каждого компонента может находится на разных серверах, так что деплой может происходить без затрагивания всей системы.

Подход 3 – использование специальных инструментов для микрофронтенда

Вы можете использовать такой инструмент, как single-spa, для подключения различных микрофронтендов.

Данное решение хорошо подходит для построений новых микрофронтенд-приложений. Если вы решили использовать single-spa, то не забудьте посмотреть их документацию, а также изучить рекомендации.

Подход 4 - Module Federation

Это особенность Webpack 5, вот некоторые подробности:

Несколько отдельных сборок должны составлять единое приложение. Эти отдельные сборки не должны иметь зависимостей друг от друга, поэтому их можно разрабатывать и развертывать по отдельности. (webpack)

Есть прекрасный пост, который объясняет это.

Примечание: вы всегда можете совмещать данные подходы для достижения той архитектуры, которая вам нужна.

Нужны ли мне микрофронтенды?

Микрофронтенды точно не нужно использовать в каждой ситуации.

Микро-(фронтенды/сервисы) решают проблемы с переписыванием и расширением программного обеспечения. Также важная особенность это независимый деплой приложений.

Все зависит от того, насколько большая у вашей компании команда разработчиков. Намного легче разрабатывать, когда не все разработчики работают с одной кодовой базой, и постоянно наступают друг другу на пятки. А вместо этого, разбиты на команды, каждая из которых работает над своей группой микро-(фронтендов/сервисов).

Проблемы с микрофронтендами

Конечно, ничего не может существовать без отрицательных сторон, давайте взглянем на эти стороны у микрофронтедов:

• Тяжелое тестирование всей кодовой базы локально, когда у вас много микро-(фронтендов/сервисов).

• В первую очередь должен быть разработан точный интерфейс.

• Больше кода для поддержки, обновлений, а также устранений проблем безопасности.

• Затраты производительности ложатся на конечного пользователя. Так как приходится скачивать каждый микрофронтенд отдельно.

• Взаимодействие между микрофронтендами может быть довольно сложным.

• Также инфраструктура и деплой станут более сложными.

Заключение

Надеюсь, что данный пост позволил Вам понять микрофронтены лучше. Спасибо за прочтение!