
Вводное слово
Всем привет! На связи Spectr и новая рубрика «Что читают наши разработчики?». Сегодня делимся статьей про микрофронтенд.
По мере усложнения веб-приложений команды стремятся найти масштабируемые и модульные подходы к разработке фронтенда. Один из таких подходов — архитектура Micro Frontend, которая позволяет разбивать монолитные интерфейсы на более мелкие модули, которые разрабатываются и разворачиваются независимо. Этот подход аналогичен принципам микросервисной архитектуры на бэкенде, где большой монолитный серверный код разбивается на небольшие независимые сервисы. В этом материале мы рассмотрим эволюцию фронтенд-разработки, принципы, лежащие в основе микрофронтендов, их преимущества, а также рассмотрим как в микрофронтендах управляются ключевые концепции, такие как Module Federation и маршрутизация.
Эволюция фронтенд-разработки
На ранних этапах веб-разработки фронтенд-приложения были относительно простыми. Обычно разработчики создавали статические сайты, используя HTML, CSS и немного JavaScript. Однако по мере того, как рос спрос на динамичные и насыщенные веб-софыты, увеличивалась и сложность веб-приложений.
Появление таких фреймворков, как Angular, React и Vue.js, стало значительным шагом вперед. Появились инструменты для создания более интерактивных и ориентированных на данные приложений. Однако такие фронтенд-приложения часто разрабатывались в виде монолитной архитектуры — больших, жестко связанных кодовых баз, которые становилось все труднее поддерживать по мере расширения команд и увеличения сложности функционала.
Чтобы решить эти проблемы, разработчики обратились к микросервисам на стороне бэкенда, которые позволили делить монолиты на более мелкие, независимо разворачиваемые сервисы. По мере того как бэкенд-архитектуры становились более масштабируемыми, стало очевидно, что те же принципы можно применить и к фронтенду.
Что такое микрофронтенд?
Подобно тому, как микросервисы разбивают бэкенд-монолиты на слабо связанные сервисы, микрофронтенды разбивают большое веб-приложение на более мелкие независимые части, которые работают вместе без сбоев, образуя целое приложение.
С помощью микрофронтендов каждая часть пользовательского интерфейса (UI) может разрабатываться и поддерживаться отдельно. Команды могут работать автономно, что обеспечивает более быстрые релизы, лучшую масштабируемость и повышенную производительность.
Почему стоит использовать микрофронтенды?
- Независимая разработка и развертывание. Каждый микрофронтенд является независимым модулем, что позволяет командам разрабатывать, тестировать и разворачивать функции без влияния на другие. 
- Технологическая независимость. Разные микрофронтенды могут быть созданы с использованием разных фреймворков (например, React для одной части, Vue.js для другой). 
- Изолированные команды.Каждая команда управляет определенной функцией или разделом приложения с четко определенными границами и ответственностями. 
- Бесшовный пользовательский опыт. Хотя микрофронтенды разрабатываются отдельно, пользователь воспринимает их как одно целое. 

Пример: Netflix
Реальный пример архитектуры микрофронтендов — это Netflix. Их веб-сайт разделен на разные секции — главная страница, поиск и настройки пользовательского профиля. Каждая из них управляется отдельным микрофронтендом. Этот подход помогает Netflix сократить время загрузки, так как каждая секция может кэшироваться независимо и обновляться по мере необходимости без влияния на весь веб-сайт. Это также позволяет быстро разрабатывать и выпускать обновления, так как изменения в одном микрофронтенде не нарушают работу других.
Отличия микрофронтендов от микросервисов
Микросервисы сосредоточены на разбиении функциональности бэкенда на независимые сервисы, микрофронтенды применяют эту концепцию к пользовательскому интерфейсу.
- Микросервисы обрабатывают функциональность бэкенда (операции с базами данных, API). 
- Микрофронтенды управляют пользовательским интерфейсом, обрабатывая взаимодействие с пользователем и слой представления. 
Несмотря на это различие, обе модели имеют общие цели:
- Слабая связь: Каждый микросервис/микрофронтенд функционирует независимо. 
- Автономия: Команды могут разрабатывать и разворачивать без необходимости координировать свои действия с другими командами. 
- Масштабируемость: Каждый сервис или фронтенд может масштабироваться независимо для удовлетворения потребностей пользователей. 
Техники интеграции микрофронтендов:
- Общие ресурсы. Храните общие ресурсы (такие как CSS и JavaScript) в центральном репозитории, обеспечивая возможность повторного и совместного использования общих ресурсов между микрофронтендами в приложении. 
- Module Federation. Эта функция Webpack 5 (или Vite) позволяет делиться и динамически загружать модули во время выполнения задач, что позволяет независимым микрофронтендам взаимодействовать друг с другом. 
- iFrames и веб-компоненты. Хотя это не настоящие техники микрофронтендов, эти подходы обеспечивают инкапсуляцию и изоляцию, особенно для устаревших систем. 
Глубокое погружение в Module Federation
Module Federation — это мощная функция в Webpack 5, которая позволяет микрофронтендам динамически делиться JavaScript-модулями друг с другом во время выполнения. Эта концепция решает ключевые проблемы в архитектуре микрофронтендов такие, как совместное использование зависимостей, уменьшение дублирования и улучшение взаимодействия.
Как это работает.
- Каждый микрофронтенд может экспортировать свои модули и использовать модули других микрофронтендов. 
- Модули загружаются асинхронно, что улучшает начальное время загрузки приложения. 
- Общие зависимости (например, React) загружаются один раз и повторно используются в разных микрофронтендах. 
Преимущества.
- Динамическая загрузка модулей. Микрофронтенды могут динамически загружать модули по мере необходимости, уменьшая время первоначальной загрузки и повышая производительность. 
- Децентрализованная архитектура. Команды управляют своими собственными модулями независимо, без необходимости координации с другими командами. 
- Общие зависимости. Зависимости могут быть общими между микрофронтендами, минимизируя дублирование и обеспечивая согласованность в приложении. 
Простая реализация с использованием React и Webpack
Давайте продемонстрируем, как микрофронтенды работают в React с помощью Module Federation в Webpack. Мы создадим два простых приложения:
- Host App — основное приложение. 
- Remote App — микрофронтенд, который будет динамически загружать основное приложение. 
Шаг 1: Настройка Remote App
- Создайте компонент HelloWorld (файл src/components/HelloWorld.js): 
const HelloWorld = () => <h1>Hello from the Micro Frontend!</h1>;
export default HelloWorld;- Обновите конфигурацию webpack (webpack.config.js): 
const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
  mode: 'development',
  devServer: { port: 3001 },
  plugins: [
    new ModuleFederationPlugin({
      name: 'remoteApp',
      filename: 'remoteEntry.js',
      exposes: { './HelloWorld': './src/components/HelloWorld' },
      shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
    }),
    new HtmlWebpackPlugin({ template: './public/index.html' }),
  ],
};
- Запустите Remote App: 
npm startШаг 2: Настройка Host App
- Установите зависимости и настройте Webpack: 
const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
  mode: 'development',
  devServer: { port: 3000 },
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: { remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js' },
      shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
    }),
    new HtmlWebpackPlugin({ template: './public/index.html' }),
  ],
};
- Загрузите удаленный компонент в файле src/App.js: 
const HelloWorld = React.lazy(() => import('remoteApp/HelloWorld'));
function App() {
  return (
    <div>
      <h1>Host App</h1>
      <React.Suspense fallback="Loading...">
        <HelloWorld />
      </React.Suspense>
    </div>
  );
}
export default App;
- Запустите Host App: 
npm startТеперь основное приложение (Host App) будет динамически загружать и отображать компонент HelloWorld из удаленного приложения (Remote App), демонстрируя работу архитектуры микрофронтендов с помощью React и Webpack.
Как это работает
Этот пример демонстрирует, как Module Federation позволяет разбивать монолитные фронтенды, таким образом приложения (например, Host) могут динамически загружать и интегрировать модули микрофронтендов (например, компонент HelloWorld) во время выполнения. Это обеспечивает независимость команд, позволяет выполнять автономное развертывание и дает возможность создавать масштабируемые, модульные фронтенд-архитектуры, сохраняя гибкость и возможность повторного использования кода.
Такой легковесный и модульный подход отражает то, как микросервисы произвели революцию в разработке бэкенда. Те же принципы применяются на фронтенде для улучшения производительности, скорости разработки и масштабируемости крупных приложений.
Обработка маршрутизации в архитектуре микрофронтендов
Маршрутизация — это важный аспект любого веб-приложения, и управление ею в микрофронтендах требует особого внимания, чтобы обеспечить бесшовный пользовательский опыт. Существуют два основных подхода к маршрутизации:
- Единый слой маршрутизации (Shell). Основное host-приложение управляет всей маршрутизацией. Оно знает о маршрутах каждого микрофронтенда и передает управление нужному фронтенду при необходимости. 
- Независимая маршрутизация. Каждый микрофронтенд управляет своей маршрутизацией автономно, что обеспечивает большую независимость. Host-приложение может по-прежнему управлять верхнеуровневыми маршрутами, но передавать управление более глубокими маршрутами соответствующему микрофронтенду. 
Общий контекст и состояние в микрофронтендах
Одной из проблем в архитектуре микрофронтендов является совместное использование состояния и контекста между несколькими микрофронтендами. Вот несколько стратегий для их управления:
- Глобальное управление состоянием. Используйте инструменты для управления состоянием (например, Redux или Zustand), которые работают во всех микрофронтендах, позволяя им делить общий контекст. 
- События и системы Pub/Sub. Микрофронтенды могут взаимодействовать друг с другом с помощью событийных систем или паттернов публикации/подписки, что обеспечивает модель взаимодействия с низкой степенью связанности. 
- Общие сервисы. Используйте общий сервисный слой (например, API Gateway или GraphQL) для предоставления общей функциональности всем микрофронтендам. 
Когда использовать архитектуру микрофронтендов
Микрофронтенды лучше всего подходят для крупных и сложных приложений, которым требуется модульность и независимая разработка. Вот ключевые сценарии, в которых они особенно полезны:
- Большие и сложные приложения. Микрофронтенды помогают разделить большие приложения на управляемые части, улучшая организацию и уменьшая время сборки. 
- Множество команд. Команды могут работать независимо над разными частями приложения, что позволяет вести параллельную разработку и выполнять автономное развертывание. 
- Независимые развертывания. Микрофронтенды позволяют обновлять определенные функции без повторного развертывания всего приложения, снижая многие риски. 
- Разные технологические стеки. Разные части приложения могут использовать разные фреймворки (например, React, Vue и т.д.), что обеспечивает гибкость в выборе технологий. 
- Масштабируемость. Микрофронтенды легче масштабировать и поддерживать, так как каждая часть приложения изолирована и может развиваться независимо. 
- Модернизация устаревших систем. Постепенная замена устаревших систем без полной их переработки, что позволяет плавно перейти на современные технологии. 
- Улучшение производительности. Оптимизация времени загрузки за счет кэширования или ленивой загрузки разных частей приложения. 
Не используйте микрофронтенды для небольших приложений или проектов с сильной необходимостью глобального совместного состояния, так как они добавляют сложность, которая может не оправдывать затраты на их реализацию.
Заключение
Архитектура микрофронтендов — это естественная эволюция для современных веб-приложений, позволяющая командам создавать масштабируемые, легко поддерживаемые и модульные фронтенды. Разделяя фронтенд на независимые модули, которые могут разворачиваться автономно, команды могут работать самостоятельно, эффективнее управлять зависимостями и создавать более гибкую архитектуру.
С помощью инструментов, таких как Module Federation, а также продуманной стратегии маршрутизации и управления состоянием, микрофронтенды открывают новые возможности для разработчиков, стремящихся преодолеть ограничения монолитных приложений. Независимо от того, работаете ли вы над крупным веб-приложением или только начинаете свой путь во фронтенд-разработке, микрофронтенды предлагают подход для создания более масштабируемых и удобных в поддержке систем.
Комментарии (18)
 - dkfbm02.12.2024 06:50- позволяет делиться и динамически загружать модули во время выполнения задач, что позволяет независимым микрофронтендам взаимодействовать друг с другом. - Это оксюморон. Как только МФЕ А начинает использовать модули МФЕ Б, он становится зависимым от Б, а команда Б не может более менять эти модули по своему усмотрению. 
 - nin-jin02.12.2024 06:50 - Ну и в качестве примера, этот портал состоит из десятка полноценных полностью независимых приложений, замиксованных в один бандл. 
 - Lewigh02.12.2024 06:50- Бесшовный пользовательский опыт: Хотя микрофронтенды разрабатываются отдельно, пользователь воспринимает их как одно целое. 
 - Большая просьба, после того как перевели статью гугл-переводчиком, ну хотя бы на разок, прочитайте ее сами или уж лучше просто выкладывайте ссылку на оригинал без всякого перевода. 
 Читать такие переводы уже на физическом уровне больно.
 - flancer02.12.2024 06:50- Разные микрофронтенды могут быть созданы с использованием разных фреймворков (например, React для одной части, Vue.js для другой). - Где-то я уже это видел - Спецификация Java-портлетов. Не взлетело. Почему не взлетело? Возможно потому, что "проблемы шерифа индейцев не волнуют". Спецификация разрабатывалась корпорациями уровня IBM & Sun, а порталы уровня Netflix оказались нужны не настолько часто, чтобы спецификация получила популярность. "Индейцы" продолжали клепать свои веб-странички и веб-сайтики из всего, что было под рукой. Наплевав на предложения корпораций. - Кстати, заметил тенденцию - по мере того, как веб становился всё более популярным на мобильных телефонах, элементы интерфейсов сайтов становились всё более крупными и простыми. Ушли в прошлое пестрящие виджетами порталы типа старого Yahoo, зато стали повсеместными сайты в стиле OpenAI  - Ну и зачем тут React для одной части и Vue для другой?  - Zenitchik02.12.2024 06:50- Не взлетело потому, что производители браузеров дружно решили выпилить поддержку Java.  - flancer02.12.2024 06:50- Ну, порталы (и портлеты) существуют до сих пор - https://www.liferay.com/ И без поддержки Java в браузере. Так что не поэтому. Слишком "тяжёлая" технология даже для энтерпрайза оказалась. 
 
 
 
           
 


dashanddot
какие нафиг команды в веб разработке, вы в курсе что все скрипты создавались чтобы домохозяйки дедали свой сайт?
если один человек не может сдедать весь бек - у вас плохой человек или плохой бек. про фронт я вообще молчу - что вообще за стыд я вечно читаю от псевдопрограммистов на скриптах
если бы такие говнокодеры делали бы базы данных и скрипты то они бы просто не раьотали бы никогда и никогда не появились
Zenitchik
Ну, напиши в монорыло продукт уровня Хабра, а мы посмотрим.
nin-jin
Дааа, чтобы опуститься до такого уровня нужна большая команда, в одно рыло такое не осилить.
Zenitchik
Кто бы говорил.
nin-jin
Тот, кто в одно рыло запилил коллаборативный визивиг редактор с прозрачной поддержкой легковесной разметки, не тормозящий и на сотне страниц сложной вёрстки.
Zenitchik
А этим редактором кто-то пользуется? Или, как обычно, он удобен только марсианам?
nin-jin
Ну вот хабраредактором кто-то пользуется, не плевался только ленивый - все они марсиане?
Zenitchik
Прямого ответа не последовало. Стало быть, Ваш редактор оказался не востребован? А хабраредактором - кто-то пользуется.
idfarm
Один программист кнопку рисует, другой ее красит, третий код выполнения пишет (сеньор не меньше), тестировщик который это тестирует, и дизайнер на отрисовку.- "Команда кнопки сохранить"