За последние несколько лет микрофронтенд, архитектурный подход, где независимые приложения собраны в одно комплексное приложение, набрал заметную популярность. Его достоинство в том, что он даёт возможность объединить в едином приложении разные виджеты, страницы, которые написаны разными разработчиками и/или командами с использованием разных фреймворков. Подробности, включая подходы к организации, — под катом.

Достоинства и недостатки микрофронтенда

О возможностях микрофронтенда уже писали на Хабре, и достаточно развёрнуто. Главное, что стоит знать, — все преимущества и возможности раскрываются при разработке больших комплексных энтерпрайз-приложений.

Вот главные плюсы:

• возможность внедрить модульную архитектуру — в этом случае отдельные виджеты или страницы работают в качестве независимых приложений

• ускорение тестирования — если меняется что-то в виджете или странице, то их можно протестировать локально, не теряя время на комплексное тестирование всего «большого» приложения

• параллельный деплой — то же самое, сохраняется модульность — все составные приложения можно деплоить независимо друг от друга

Есть, конечно, и недостатки:

• сложность приложения увеличивается, и весьма значительно

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

• достаточно часто возникают проблемы с кешированием и версионностью приложений

Всё это говорит об одном — микрофронтенд стоит применять только в больших командах, которые работают над комплексными проектами. Если проект небольшой, а команда одна, притом это несколько человек, лучше использовать другой архитектурный подход. Конечно, могут быть и исключения, но их не так много. Если ваша команда — именно это исключение, расскажите об этом в комментарии — всем будет интересно.

Микрофронтенд в большинстве случаев позволяет ускорить разработку за счёт выделенных зон ответственности каждой из команд, а также изолированного тестирования. То есть речь идёт об оптимизации процессов разработки.

Ну а теперь — о подходах в микрофронтенде

Их не так много, и у каждого, как всегда, есть свои недостатки и преимущества.

Iframe

Очень известная технология, которая нашла новую жизнь в реализации микрофронтенд-архитектуры. На Хабре любой новичок знает об iframe, так что повторяться, описывая эту технологию, не стоит. А вот о преимуществах и недостатках, пожалуй, расскажем.

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

Но это преимущество достигается за счёт производительности, ведь каждая новая вставка iframe — добавление нагрузки. Этот фактор можно нивелировать, оптимизировав кеширование.

Что касается недостатков, то главный из них — взаимодействие с поисковыми роботами. Они не в состоянии отрисовывать iframe для каждого нового индексирования — соответственно, страдает SEO.

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

NPM

Речь идёт о разработке с использованием пакетов NPM, что даёт несколько преимуществ — от производительности до SEO. В частности, нужные компоненты и файлы можно импортировать из библиотеки. В ходе разработки сохраняется типизация и нет проблем с версионностью, как в предыдущем варианте.

С другой стороны, приходится сохранять единство стека, а также следить за версионностью микрофронтенда и транзитивными зависимостями. Тут есть и обратная сторона медали — всё это позволяет без проблем подхватить разработку со стороны других команд. Зачем? Например, нужно добавить, изменить или удалить какие-то функции.

Подмодули git и монорепозитории

Это альтернатива предыдущему варианту. Помните мем «Мы установили тебе телевизор в телевизор, чтобы ты мог смотреть телевизор, пока смотришь телевизор»? Ну или как-то так. Здесь суть примерно та же — получаем репозитории внутри репозитория, внутри которых могут быть… Ну вы поняли.

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

Достоинства и недостатки примерно те же, что и в предыдущем варианте. Но есть ещё один минус — если нужно добавить какую-то новую возможность сразу во все пакеты одновременно, сделать это будет сложно. Слить все изменения вместе не получится.

Single-spa

А это подход, у которого почти нет недостатков, зато много преимуществ:

• очень хорошая документация

• можно шарить зависимости между отдельными виджетами

• есть поддержка независимых деплойментов

• есть рабочие примеры с использованием популярных современных фреймворков и библиотек

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

Сам по себе Single-spa — фреймворк, позволяющий объединять разные приложения, причём вне зависимости от того, какие библиотеки или фреймворки в них используются. То есть это идеальный вариант для микрофронтенда.

Вот так примерно выглядит приложение, где используется этот подход:

Кстати, схема похожа на iframe, но загрузка реализуется посредством нативного импорта + importmap или через Systemjs.

Недостатков почти нет, главный из них, как и в случае с iframe, — сложности с SEO. Но если поисковая оптимизация особо и не нужна, то этот подход крайне рекомендован, технология очень мощная.

Webpack 5 Module Federation

Отличный плагин, который разработан специально для микрофронтенда. Он позволяет выполнять корректную сборку с динамическим импортом во время выполнения. Развёртывание полностью независимое, а реализация — очень лёгкая.

Недостатков почти нет.

Что в итоге?

Микрофронтенд рекомендован тем проектам и командам, где:

• есть необходимость в расширении

• работает больше 10, а лучше 20 человек

• приложение состоит из отдельных модулей, которые могут быть и отдельными приложениями

• тестирование и багфиксинг занимают много времени

В противном случае, за малыми исключениями, этот подход лишь усложнит разработку, а не упростит процесс.

Если вы используете микрофронтенд в работе, расскажите о своём опыте и кейсах: когда начали использовать, какие выгоды получили и т. п.