Я написал данный пост, так как чувствую, что Микрофронтенды это стало не просто модное слово, они уже начали распространятся на большие проекты.
Микрофронтенды могут быть следующей важной вехой в фронтенд разработке.
Давайте я вам расскажу почему!
Что такое микрофронтенды?
Микрофронтенды – это определенная структура архитектуры кода для фронтенд приложений. Все это берет начало из микросервисов на бэкенде.
Для понимания микрофронтендов и почему они нам нужны, в первую очередь нам необходимо узнать немного о них.
Микросервисная архитектура — вариант сервис-ориентированной архитектуры программного обеспечения, направленный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — микросервисов, получивший распространение в середине 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)
Есть прекрасный пост, который объясняет это.
Примечание: вы всегда можете совмещать данные подходы для достижения той архитектуры, которая вам нужна.
Нужны ли мне микрофронтенды?
Микрофронтенды точно не нужно использовать в каждой ситуации.
Микро-(фронтенды/сервисы) решают проблемы с переписыванием и расширением программного обеспечения. Также важная особенность это независимый деплой приложений.
Все зависит от того, насколько большая у вашей компании команда разработчиков. Намного легче разрабатывать, когда не все разработчики работают с одной кодовой базой, и постоянно наступают друг другу на пятки. А вместо этого, разбиты на команды, каждая из которых работает над своей группой микро-(фронтендов/сервисов).
Проблемы с микрофронтендами
Конечно, ничего не может существовать без отрицательных сторон, давайте взглянем на эти стороны у микрофронтедов:
Тяжелое тестирование всей кодовой базы локально, когда у вас много микро-(фронтендов/сервисов).
В первую очередь должен быть разработан точный интерфейс.
Больше кода для поддержки, обновлений, а также устранений проблем безопасности.
Затраты производительности ложатся на конечного пользователя. Так как приходится скачивать каждый микрофронтенд отдельно.
Взаимодействие между микрофронтендами может быть довольно сложным.
Также инфраструктура и деплой станут более сложными.
Заключение
Надеюсь, что данный пост позволил Вам понять микрофронтены лучше. Спасибо за прочтение!
