Микрофронтенды (MFE) в наши дни являются горячей темой в кругах веб-разработчиков. Но что это такое? В двух словах, MFE — это способ структурирования веб-приложения в виде набора небольших, независимо развертываемых модулей. Каждый модуль имеет собственный пользовательский интерфейс, бизнес-логику и модель данных, и его можно разрабатывать, тестировать и развертывать независимо от других модулей. Хотя термин микрофронтенд использовался в нескольких статьях и проектах в прошлом, только когда Зак Джексон выпустил основной плагин под названием Федерация модулей в 2020 году, кампания за эту концепцию действительно началась, что принесло широкое признание и внимание.

Преимущества микро-интерфейсов

Существует несколько преимуществ использования архитектуры микроинтерфейса в новых и существующих проектах, наиболее очевидным из которых является большая гибкость и модульность при разработке пользовательского интерфейса и уровня представления. Каждая команда может разрабатывать свои собственные компоненты пользовательского интерфейса, не беспокоясь о нарушении функций других команд. Некоторые другие преимущества включают в себя:

  • Лучшее разделение обязанностей. Каждая команда может сосредоточиться на своей области приложения, не беспокоясь о деталях реализации других команд.
  • Простая параллельная разработка. Несколько команд могут одновременно работать над разными частями приложения без необходимости координировать свои усилия.
  • Более простое тестирование и отладка отдельных модулей. Каждая команда может тестировать и отлаживать свои собственные компоненты пользовательского интерфейса, не беспокоясь о компонентах других команд.
  • Повышение производительности. Каждая команда может оптимизировать свои собственные компоненты пользовательского интерфейса, не беспокоясь о производительности других команд.
  • Масштабируемость и проблемы, связанные с масштабированием, можно легко решить. Каждая команда может масштабировать свои собственные компоненты пользовательского интерфейса, не беспокоясь о других командах, компонентах или модулях.
  • Развертывание. Каждому модулю можно выделять ресурсы по своему усмотрению, не затрагивая другие части более крупного приложения, при этом каждый модуль можно развертывать отдельно, что делает его идеальным кандидатом для эффективного управления ресурсами.

Недостатки микро-интерфейсов

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

  • Сложности с синхронизацией различных модулей друг с другом. Если одна команда вносит изменение, которое нарушает интерфейс между двумя модулями, может быть очень сложно отследить источник проблемы.
  • Сложности при тестировании всего приложения или его отладке. Когда несколько команд работают над разными частями кода, может быть сложно воспроизвести условия, при которых возникает ошибка.
  • Микроинтерфейсная архитектура может затруднить совместное использование кода между различными частями приложения. Если каждая команда работает изолированно, может быть сложно повторно использовать код, разработанный другой командой.
  • Кто-то может возразить, что это форма важнее функции.
  • По иронии судьбы, может быть сложно интегрировать разные компоненты вместе, если они зависят друг от друга. Чтобы это не было проблемой, установите лучшие практики и соглашения между командами.

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

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

Как реализовать архитектуру микро-интерфейса.

Существует несколько различных способов реализации модулей или компонентов микроинтерфейса. Наиболее распространенным подходом является использование библиотеки JavaScript, такой как библиотеки и инструменты React, Vue или даже SSR (рендеринг на стороне сервера). Каждая команда может разработать свои собственные компоненты пользовательского интерфейса, используя библиотеку по своему выбору, а затем использовать такой инструмент, как веб-пакет или накопительный пакет, для создания единого пакета, включающего все компоненты пользовательского интерфейса.

Другой подход заключается в использовании таких фреймворков, как Ember или Angular, которые помогают правильно организовать компоненты и сделать их легко отсоединяемыми. Важно отметить, что с архитектурой микроинтерфейса каждая команда может разрабатывать свои собственные компоненты, используя фреймворк или библиотеку по своему выбору, а затем использовать такой инструмент, как веб-пакет или накопительный пакет, для создания единого пакета, включающего все компоненты. Примеры реализации архитектуры микроинтерфейса широко доступны, и одним из популярных источников является репозиторий примеров федерации модулей на GitHub, см. https://github.com/module-federation/module-federation-examples для получения дополнительной информации.

Хранение и совместное использование кода

Monorepo — одна из широко используемых настроек при работе с репозиторием кода на основе git. Эта концепция обеспечивает локальный доступ к другим компонентам и позволяет разработчикам легко вносить изменения в компоненты без дополнительных усилий. Однако некоторые команды не используют совместно репозитории кода и все равно работают эффективно. Нужно учитывать, как часто взаимодействуют команды, насколько связаны компоненты, и решать, как организовать код на основе этой информации. Также важно правильно разделить компоненты таким образом, чтобы они были как можно более независимыми с точки зрения кода, данных и функций.

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

Отдельные компоненты в одном приложении или контейнере

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

Создание и развертывание

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

Все компоненты должны иметь свой специальный процесс сборки или этап либо как часть более крупного конвейера, либо как отдельные конвейеры. Это позволяет компонентам быть по-настоящему независимыми и развертываться по отдельности. Команды могут использовать контейнеризацию, например Docker, чтобы помочь организовать процесс развертывания и сборки. Каждое изменение в компоненте может иметь версию с использованием семантического управления версиями, а развертывание обновлений версии может быть автоматизировано, контролируемо или вручную в зависимости от бизнес-требований.

По большей части существующих конвейерных решений, таких как GitLab и GitHub Actions, Jenkins и им подобных, должно быть достаточно для создания и развертывания отдельных компонентов. Не имеет значения, развернуты ли они в облаке или на пользовательских серверах, в модулях, службе приложений Azure или даже в виде файлов в корзине s3, существующих решений должно быть достаточно, поскольку они легко настраиваются для разделения большого проекта на более мелкие части.

Отдельные компоненты также могут быть развернуты в частных реестрах пакетов, таких как nexus, с использованием NPM или других доступных вариантов. Таким образом, компоненты можно было легко импортировать, создавать и управлять ими. Команды могут решить, какие версии сторонних компонентов они хотят установить, и отслеживать историю изменений. Это особенно полезно для общих компонентов и сервисов.

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

Предоставление модулей MFE для общего доступа

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

Помимо использования существующих решений, встроенных в фреймворки и библиотеки для передачи данных, маршрутизации и создания контейнера для ваших компонентов, приложения-контейнеры также могут быть простым или сложным сервером Ngnix, приложением Express, проектом Astro среди других доступных вариантов, поскольку их основная роль для маршрутизации трафика и представления различных компонентов, работающих на выделенных портах, URL-адресах в локальной сети, кластерах Kubernetes или общедоступной сети. Различные части приложения могут иметь свои собственные конфигурации брандмауэра, уровни доступа, права и при этом эффективно работать вместе без проблем, поскольку каждая из них будет работать в своей собственной мини-сети, контейнере и порту, правила могут применяться на верхнем уровне, балансировщики нагрузки могут быть настроены, и трафик можно легко управлять.

Совместное использование данных

Совместное использование данных между различными модулями и компонентами в приложении на основе MFE может быть сложным. Есть несколько важных частей, которые следует отметить, и некоторые основные правила, которые применяются. По большей части менеджер состояния может быть использован для управления данными локальных компонентов, а также для обмена данными между внешними компонентами. Инструменты управления состоянием, такие как Redux, хорошо работают с компонентами микроинтерфейса, поскольку каждая команда может управлять своими локальными данными в своих компонентах и, кроме того, предоставляет возможность совместного использования данных. В Angular можно использовать такие инструменты, как RxJS и сервисы с наблюдаемыми, в отличие от использования внешнего инструмента управления состоянием для беспрепятственного управления и совместного использования данных компонентов.

Одна из важных вещей, которую следует отметить, заключается в том, что данные должны быть максимально разделены, чтобы сделать их независимыми и уникальными для отдельных компонентов, что должно быть целью при получении данных от сторонних API или от пользовательского ввода. Минимизация объема данных, совместно используемых компонентами, и обеспечение управления общим состоянием таким образом, чтобы только компонент, ответственный за его изменение, имел доступ для записи, а другие только потребляли/читали данные. Обновление данных, когда в обновлении участвуют несколько компонентов, должно выполняться в порядке очереди, когда применяется первое поступившее обновление, за которым следует следующее, чтобы создать плавный переход состояния и в целом эффективную систему.
Также важно убедиться, что компоненты могут игнорировать ненужные данные, события и изменения в данных, которые могут вызвать их повторную визуализацию, когда внутри компонента не вносятся прямые изменения. Настоятельно рекомендуется внедрить эффективную стратегию обнаружения изменений и отказаться от подписки на поток данных, когда они больше не нужны.

Лучшие практики для микро-интерфейсов

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

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

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

‍

Первоначально опубликовано на https://www.itmagination.com.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord . Заинтересованы в хакинге роста? Ознакомьтесь с разделом Схема.