В октябре прошлого года, с выходом Webpack 5, разработчикам стал доступен плагин для этого популярного сборщика модулей JS Module Federation (MF, - прим. ред.). Согласно недавнему заявлению основного разработчика плагина, Зака Джексона (Zack Jackson, - прим. ред.), свои проекты на него перевели уже около 4000 крупных технологических компаний по всему миру, в том числе TikTok, Business Insider, Adidas и Best Buy. Компаний, которые адаптируют у себя MF, но не объявляли об этом, намного больше, добавляет З. Джексон.

Плагин MF примечателен прежде всего тем, что это первый фреймворк, который автоматизирует и стандартизирует создание новых микрофронтендов. «Микрофронтенды» – это микросервисы на фронтенде. О том, стоит ли переводить свои проекты на MF или это только мода, а также о том, почему вслед за backend-ом архитектуру на микросервисах воспроизводят в UI/UX интерфейсах для пользователей сайтов и приложений, мы поговорили с Ринатом Юнусовым, тимлидом и frontend-разработчиком с более чем 9-летним опытом в индустрии.

• Действительно ли Module Federation является прорывным и лучше других реализаций микрофронтендной архитектуры на Webpack 5, которые уже существовали?
• Короткий ответ «да». И этому множество причин. До 2020 были компании, которые строили пользовательские интерфейсы на микрофронтендах. Делалось это с использованием самых разных технологий, которые задумались первоначально не для этого. Есть подходы на основе SSD Server-Side Fragment Composition), на основе iframes, single SPA, Web Components ряд других вариантов, включая абсолютно самобытные решения, написанные разработчиками специально для их компаний. Module Federation изначально создавался, чтобы поставить на конвейер создание фронтендных микросервисов (мифровротнтендов) и легко объединять все созданное в единый интерфейс для пользователя.

 
Так как микросервисы – специализация Module Federation, неудивительно, что приложения и сервисы с такой архитектурой на MF работают лучше, чем то же самое, выполненное по-старому. Мы сами усомнились, например, в том, что приложение на Module Federation будет работать в несколько раз быстрее, однако нами был проведен эксперимент и это так! Коллеги запустили один и тот же интерфейс на микрофронтендах с iframe, а потом на MF и что же? В первом случае скорость загрузки (page load time, - прим. ред.) составила 0,02 (0.020034313201904297, - прим. ред.), а во втором – 0,006 (0.006508827209472656). Другими словами, React-приложение на 307% быстрее после перехода на Module Federation.
Это вполне измеримый результат, который позволяет говорить, что фреймворк не просто «очередной способ» создания микрофронтендов, а «лучший из имеющихся». На самом деле, скорость, лишь одна позиция, по которой MF лучше. В нем учтено и исключено все то, что «бесило» разработчиков до последнего времени. При переходе между страницами не происходит перезагрузок, если в компоненте использован shared-модуль, приложение не перекомпилируется, нет дублирования vendor-кода, когда он уже предоставлен другими сборками, например, тем же React, то есть повторно его не приходится обрабатывать.
Да, добавлю, что «умный сервер» уже не нужен. Все происходит на стороне клиента, у него в браузере. Кстати, вы сказали в вопросе про Webpack 5, но сейчас Module Federation работает уже не только с ним, а еще с Rspack, Vite, Rollup, esBuild. Таким образом, к числу плюсов MF надо теперь добавлять и кросс-платформенность.

• Насколько быстро можно освоить и перейти на этот фреймворк с того стека, который в компании использовали раньше?
• Module Federation прост и понятен. Можно практически сразу начать разделять ваше монолитное приложение на микрофронтенды (если это ваш случай) или упрощать свои микрофронтенды, если вы уже с ними работаете. Детали усваиваются на ходу. Вы установили плагин Module Federation в свое окружение. Теперь у вас есть файл package-lock.json.
Необходимо прописать зависимости. Синтаксис очень прост. Вы, по сути, просто перечисляете порты или сервера, на которых у вас расположены отдельные компоненты приложения и сервиса. Напомню, что суть микросервисов и микрофронтендов в том, что вы можете разделить свой IT-продукт на маленькие кусочки кода, размещенные на разных серверах (портах) и собирающиеся вместе по запросу пользователя в рантайме. Преимуществ множество: отказоустойчивость – каждый микрофронтенд соединен с другими только http запросом или строкой в бандле webpack. Решение старой проблемы, что методы в монолитном приложении могут быть подключены сразу в нескольких компонентах и изменения на скорую руку заставляют «слетать» что-нибудь неожиданное.
Эдакое идеальное воплощение принципа инкапсуляции на стратегическом уровне! Когда вы прописали подключения портов и серверов, на которых разложены ваши компоненты, настает время создать экземпляр класса ModuleFederationPlugin, который будет родительским для конфигов отдельных микрофронтендов (компонентов). Делается это в файле webpack.config.js. Это главный host, управляющий подключением отдельных микрофронтендов. А теперь предположим, что нам нужно создать слайдер на странице. Это один отдельный микрофронтенд. Мы просто прописываем его несложной конструкцией из официальной документации фреймворка в файле webpack.config.js. Единственное, не забудьте зарегистрировать новый объект в App.tsx. Иначе работать вся эта конструкция не будет!

• Почему во frontend-разработке так заговорили о микрофронтендах. В backend-девелопменте идея микросервисов муссировалась еще с 2012. Почему именно сейчас концепт так успешно перекочевал «на фронт»?

• Проблемы копились и именно в последние годы количество перешло в качество. Во-первых, существующие «костыли» с тем же ifarme не позволяли быстро разрабатывать IT-решения. Если в Module Federation многое решено и автоматизировано «под капотом», то с iframe было очень много сложностей и тормозящих работу моментов. Те же CSS файлы, которые у модальных окон постоянно отказывались работать как следует. Кто пробовал – помнит. Были и с SEO проблемы после таких вот «костылей».
MF – совсем другое дело. Настоящая машина по производству микрофронтендов. Имевшихся до 2020 решения не давали возможности уйти полноценно от монолитной архитектуры во frontend, а между тем, она уже доказала свою архаичность. Один компонент востребован в ряде приложений. Создать на его основе кастомный фреймворк и подключать его везде, конечно, можно, но это время, которое деньги. После окончательной сборки неповоротливый монолит оказывается чересчур тяжелым, что отражается на всех технических метриках получившегося продукта. А сколько скандалов и склок бывало в командах разработчиков из-за того, что несколько групп затрагивают работу друг друга.
Микросервисы, а теперь и микрофронтенды решают эти и многие другие проблемы. Устоявшейся практикой считается не делать один отдельно взятый микрофронтенд большим. Считается, что нельзя давать ему разрастаться так, чтобы у поддерживающих его программистов требовалось более двух недель, чтобы полностью его переписать. Это хороший подход, так как одна из главных трагедий микросервисов – превращение каждого из них в новый монолит со всеми родовыми пятнами и проблемами.
Микрофронтенды только подключаются при сборке окончательного проекта, поэтому сами по себе достаточно независимы. Вы можете закрепить за каждым микрофронтендом свою группу специалистов или даже поручить каждому специалисту по одному ресурсу. Конфликтов больше не будет, поскольку отдельный микрофронтенд не влияет на другой. Вы даже можете написать один из них на каком-нибудь фреймворке JS, а другой – на TypeScript. Все будет хорошо работать. Полезная особенность с точки зрения безопасности сервисов, так как многие угрозы (хакинг и так далее) можно превентивно устранить на уровне языков. Есть бонусы микросервисов в самых разных аспектах. В том же тестировании.
Поскольку неработоспособность какого-нибудь микрофронтенда или мироксервиса не обваливает все по цепочке, баг легче локализовать и профилировать. Так как отдельно взятый микрофронтенд очень простая программа, то и написана она просто. Улучшается читаемость и исправить такой код, раз ошибка уже найдена, тоже гораздо проще. Разумеется, эти и многие другие преимущества лучше всего почувствуют в больших, высоконагруженных проектах, где велика цена ошибки, временные затраты растут по экспоненте из-за эффекта масштаба. Для больших проектов идея разделить большой frontend на части покажется очень привлекательной. Разработчики Module Federation сами предлагают ряд конкретных реализации микрофронтендной архитектуры, которые можно использовать. Можно иметь контейнер оболочки отдельной сборкой и «компилить» каждую страницу из отдельного контейнера, применяя эту сборку.
Каждый раз при новом роутинге оболочка будет собираться заново для каждой страницы. Можно выделять для библиотек и фреймворков отдельные контейнеры, чтобы избежать проблему монолитов (приложений с монолитной архитектурой), если библиотека – контейнер, то ее можно переподключить или заменить без переустановки и изменения всех микрофронтендов Есть возможность вызывать объект общей области (shared scope) и динамически, асинхронно, подключать различные микросервисы по мере надобности. Плагин Module Federation содержит для этого специальные методы get и init (метод, обеспечивающий асинхронность).

• Есть мнение, что Module Federation – очередная мода и через некоторое время придется переходить на что-нибудь еще. Кто-то считал JQuery вечной библиотекой… А вы как считаете?
• Нет, MF с нами надолго и со мной, видимо согласны разработчики ключевых фреймворков JS. Например, в Angular уже добавили функционал интеграции с MF. На webpack основан NextJS, а MF плагин этого самого webpack, который будет легко добавить в стек технологий проекта.

• Какие проблемы вы бы отметили в применении Module Federation российскими и иностранными командами разработчиков, которые уже решились на переход?
• Фреймворк сравнительно новый. Проблемы действительно есть. Я упомянул Next.js, но пока совместимости с MF не удалось достичь. Next исповедует асинхронность, а Module Federation – нет. В итоге вылезли неприятные моменты. При сочетании двух технологий, если у вас в одном микрофронтенде, размещенном в отдельном, например, контейнере Docker библиотека новой версии. а в других другой, более старой, то MF возьмет и применит эту одну ко всем микрофротендам. К счастью, есть некоторые способы, которые уже изобрели разработчики, чтобы обойти данный казус, но Module Federation любят за то, что «костыли» не нужны.
Следующий момент. Module Federation взаимодействует с одной какой-нибудь библиотекой JS. Вы не подключите React через Vue! Забудьте также про CDN подключения популярных библиотек. Так, например, работает Bootstrap (правда, есть и другие способы ее подключить, это просто один из удобных). Иногда возникают, к сожалению, проблемы распознавания даже с обычными css старых проектов. При миграции на Module Federation.

• А вы уже переводите свои проекты на Module Federation?
• Еще бы, часть проектов уже перевели, активно работаем с микрофронтендами! Я думаю, что переходить на фреймворк именно сейчас – верное решение. Во-первых, MF, как я уже сказал, не мода и в дальнейшем плагин будет обычным решением проблемы с хорошим коммьюнити заинтересованных разработчиков, качественной документацией. Во-вторых, он ускорит и оптимизирует проект. В-третьих, специалисты по кибербезопасности сообщают о росте атак на IT-инфраструктуру, в том числе в связи с ситуацией в экономике политике. В Darknet продают информацию об уязвимостях. Монолитная архитектура слишком чувствительна к угрозам, а микрофронтенды – решение проблемы. Ну и почему доводом не может считаться переход флагманских технологических компаний на Module Federation? За рубежом его адаптировали у себя гиганты Netflix и Amazon, а в России Delivery Club. Если «большая рыба» куда-то идет, с большой вероятностью полезно идти туда же. Как говорится, «миллион леммингов не могут ошибаться»!

Автор статьи: Левков Сергей Александрович