Сегодня микрофронтенды больше не являются подтверждением концепции. Если мы поищем в Интернете, мы сможем найти множество примеров внедрения Microfrontend. Кроме того, большинство этих веб-приложений уже работают, что доказывает свою надежность.
Однако важно следовать лучшим практикам и выбирать правильные инструменты, чтобы добиться успеха с Microfrontend. В противном случае Microfrontends может быстро превратиться в накладные расходы для ваших команд, рискуя общим ростом проекта.
В этой статье я собираюсь поделиться некоторыми лучшими практиками, связанными с Microfrontend, и порекомендовать несколько инструментов для внедрения этих методов в ваши проекты.
1. Структура кода и компоненты
При переходе на Microfrontends одно из важнейших решений, которые вы должны принять, - это выбрать подход, используемый для структурирования кода.
Существуют два традиционных метода: Distributedrepo и Monorepo. Помимо этих двух, существуют гибридные подходы, которые находятся где-то посередине.
В подходе Distributedrepo микрофронтенды разделены на несколько репозиториев, жизненный цикл которых управляется отдельно. В Monorepo все микрофронтенды будут находиться в одном репозитории.
Подход распределенного репо
Подход с распределенным репозиторием является более гибким, но он сталкивается с серьезной проблемой совместного использования компонентов пользовательского интерфейса для поддержания согласованного пользовательского интерфейса между MF (что обычно означает поддержку компонентов пользовательского интерфейса в виде библиотек NPM, что создает накладные расходы на поддержку различных конвейеров сборки, разных репозиториев. , и несовпадения версий).
Хороший пример реализации подхода Micro Frontends и решения проблемы совместного использования компонентов пользовательского интерфейса между ними можно увидеть в Bit.dev.
Маркетинговый сайт Bit.dev состоит из двух групп компонентов React, публикуемых и управляемых платформой Bit. Две группы были построены и доставлены отдельно. Момент интеграции наступает во время сборки в кодовой базе, которая использует компоненты из обеих коллекций. Всякий раз, когда доставляется новая версия компонента, происходит новая интеграция.
Наведите указатель мыши на различные компоненты на целевой странице Bit, чтобы увидеть объем или коллекцию каждого компонента. Щелкните имя компонента (вверху), чтобы проверить компонент и / или установить его в свой проект.
Как упоминалось ранее, указанная выше страница построена из компонентов, разработанных в двух разных базах кода в двух разных репозиториях GitHub. Компоненты каждой кодовой базы публикуются в соответствующих коллекциях Bit.
- base-ui: Github | Сбор на Bit
- евангелист: Github | Сбор на Bit
Коллекция base-ui служит дизайнерской системой Bit. Его компоненты также публикуются на Bit. Стоит отметить, что каждый компонент публикуется, версируется и используется индивидуально.
Компоненты, опубликованные в коллекции евангелистов (используемой для маркетинговых страниц Bit), используют некоторые компоненты, доступные в коллекции base-ui, для поддержания единообразного внешнего вида.
Подход монорепозитория
Если вы последуете подходу Monorepo, вы не столкнетесь с теми же проблемами управления общими компонентами, как раньше. Но, как следует из названия, все команды будут работать в одном репозитории, где необходимо четко определить право собственности на сегменты кода. Кроме того, очень важно наладить управление кодом и зависимостями между Microfrontend.
Один из лучших инструментов для подхода Monorepo - NX, Extensible Dev Tools for Monorepos. В настоящее время NX "из коробки" поддерживает как Angular, так и React. Основное преимущество NX заключается в том, что он предоставляет структуру для Monorepo и базовый набор инструментов для DevOps и управления.
Дополнительную информацию о том, как NX работает на практике, можно найти в видеоролике Nx: Extensible Dev Tools for Monorepos.
2. Управление зависимостями
При создании Microfronends управление зависимостями влияет на проект двумя способами. Одним из распространенных требований является управление сторонними зависимостями. Другой элемент - обработка общего кода, такого как утилиты и фреймворки, которые хорошо вписываются в библиотеки NPM (применимо для подхода Distributedrepo). Эти библиотеки нам необходимо опубликовать в репозитории для доступа из каждого Microfrontend, аналогично сторонним зависимостям.
Один из лучших способов управления как внутренними, так и внешними библиотеками - использовать частный репозиторий артефактов. Мы можем публиковать код внутренней библиотеки в репозитории артефактов, а также проксировать сторонние библиотеки (также работает как резервная копия) и доставлять в Microfrontends из одного места. Помимо предоставления доступа к библиотекам, использование хранилища артефактов поможет обеспечить управление версиями, используемыми в Microfrontend.
Один из инструментов, который я бы порекомендовал для этого, - использовать Артефакты Azure DevOps. Если вы по какой-либо причине не используете Azure DevOps, вы можете найти несколько других инструментов, которые выполняют ту же работу.
3. Тематика пользовательского интерфейса
Одной из стандартных практик тематики пользовательского интерфейса для веб-приложений является использование инфраструктуры пользовательского интерфейса, такой как Material, Bootstrap (или конкретной реализации, такой как NGX Bootstrap) и т. Д. Эти структуры пользовательского интерфейса предоставляют стандартные элементы пользовательского интерфейса, стили и возможность настройки темы. В Microfrontends важно поддерживать постоянство компонентов пользовательского интерфейса, чтобы общая тема приложения выглядела согласованно.
Поэтому, если вы используете подход Distributedrepo, рекомендуется экспортировать тематику и стандартные элементы пользовательского интерфейса в частную библиотеку NPM с CSS, совместно используемым в Microfrontend. Для той же цели можно использовать артефакты Azure DevOps.
4. DevOps
Использование правильных инструментов и практик в DevOps даст немедленные результаты. Кроме того, это область, в которой есть множество инструментов и методов, которые вам нужно выбирать в зависимости от ваших базовых технологий и платформ. В этой статье я коснусь в основном автоматизации CI / CD, качества кода, телеметрии и мониторинга для Microfrontends.
CI / CD автоматизация
Использование автоматизации важно как для микрофронтендов, так и для микросервисов. С учетом дополнительной сложности, связанной с Microfrontends, автоматизация является ключом, обеспечивающим точность и скорость доставки.
В контексте Microfrontend нам необходимо настроить автоматизацию для сборки кода, интеграции (в зависимости от подхода Microfrontend), а также провести модульные и интеграционные тесты. Одним из важных шагов с Microfrontends является проверка работы приложения в целом после развертывания. Вы можете использовать инструмент непрерывной автоматизации, такой как Cypress, для написания сценариев автоматизации для проверки работоспособности веб-приложения.
Поскольку CI / CD - это широко распространенная практика, я не буду выделять какие-либо конкретные инструменты. Но вы можете использовать любые другие средства для автоматизации, чтобы устранить проблемы, упомянутые выше.
Качество кода
Когда мы используем Microfrontends, важно поддерживать согласованность кода и контролировать его качество. В отличие от микросервисов, вы, скорее всего, будете использовать один и тот же стек технологий во всех микрофронтендах. Следовательно, важно обеспечить соблюдение правил для поддержания качества кода в Microfrontend.
Один из инструментов, который я мог бы настоятельно рекомендовать, - это SonarCloud, где он поможет установить порог качества для непрерывного контроля качества кода, а также получить общие матрицы качества приложения.
Телеметрия и мониторинг
Для Microfrontend я бы рекомендовал отслеживать поведение самого Frontend. Хорошей практикой является мониторинг внешних интерфейсов как практика, поскольку риск отказа Microfrontends выше, чем у одного внешнего интерфейса по очевидным причинам. Один из инструментов, который я мог бы предложить, - это использовать Azure AppInsights с их SDK JavaScript для трассировки от внешнего интерфейса до всей инфраструктуры внутреннего интерфейса. Лучше всего, если ваш бэкэнд также использует .NET.
Если вы работаете на другой платформе, вы, вероятно, можете найти аналогичные инструменты, которые выполняют ту же работу. Наиболее важным фактором является наличие инструментов для мониторинга всего приложения без игнорирования части Frontend.
Резюме
В целом, я надеюсь, что вы ознакомились с лучшими практиками работы с Microfrontend, описанными в этой статье. Однако важно отметить, что эти методы постоянно развиваются, и очень важно применять их в зависимости от вашего приложения, структуры команды и организации.
Кроме того, есть различные существующие инструменты, которые мы можем использовать для разработки Frontend, которые по-прежнему применимы к Microfrontend. Поэтому не ограничивайте инструменты, упомянутые в этой статье, и попытайтесь изучить возможность использования инструментов, с которыми вы знакомы, для поддержки передовых методов, обсуждаемых в этой статье.
Наконец, важно понимать, что Microfrontends - не лучший выбор для всех. Поэтому, прежде чем переходить на Microfrontend, изучите исходные данные, на правильном ли вы этапе и подходите ли вы для выбора архитектуры Microfrontend для своего приложения.
