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