Отладка Node.js с помощью Google Chrome

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

Тем не менее важно следовать лучшим практикам и выбирать правильные инструменты для достижения успеха при работе с микрофронтендами. В противном случае они могут стать накладными расходами для команд и превратиться в риск для общего роста проекта.

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

1. Структура кода и компоненты

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

Обычно используются два общепринятых метода: Distributedrepo и Monorepo. Помимо этих двух существуют также гибридные подходы.

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

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

Подход с использованием распределенных репозиториев является более гибким, но главный его недостаток связан с обменом UI-компонентов для поддержания согласованности пользовательского интерфейса в разных MF (обычно это означает поддержание UI-компонентов как библиотек NPM, что создает дополнительные затраты на поддержку различных конвейеров сборки, репозиториев и несовпадений версий).

Хороший пример реализации этого подхода на основе микрофронтендов и решения проблемы совместного использования UI-компонентов между ними можно увидеть в Bit.dev.

Маркетинговый веб-сайт Bit.dev состоит из двух групп компонентов React, опубликованных и управляемых платформой Bit. Обе группы были построены и доставлены по отдельности. «Момент интеграции» происходит во время сборки в базе кода, которая использует компоненты из обеих коллекций. При каждом появлении новой версии компонента происходит новая интеграция.

Наведите указатель мыши на различные компоненты на целевой странице Bit, чтобы увидеть «область действия» или «коллекцию» каждого компонента. Нажмите на имя компонента (сверху), чтобы проверить компонент или даже установить его в свой проект.

Целевая страница Bit, состоящая из независимых компонентов

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

• base-ui: Github | Коллекция в Bit;
• evangelist: Github | Коллекция в Bit.

Коллекция base-ui служит системой дизайна Bit. Ее компоненты также публикуются в Bit. Стоит отметить, что каждый компонент публикуется, версионируется и используется по отдельности.

Компоненты, публикуемые в коллекции evangelist (применяются для маркетинговых страниц Bit), используют некоторые компоненты, доступные в base-ui, для обеспечения единого внешнего вида.

Подход с использованием единого репозитория

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

Одним из лучших инструментов для этого подхода является NX — набор расширяемых инструментов разработчика для единых репозиториев. В настоящее время NX поддерживает Angular и React из коробки. Основным его преимуществом является то, что он предоставляет структуру для единого репозитория и базовый набор инструментов для DevOps и управления.

Больше информации о том, как NX работает на практике, можно узнать из этого видео.

2. Управление зависимостями

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

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

Для этого я хочу порекомендовать такой инструмент, как Azure DevOps Artifacts. Если вы по какой-либо причине не используете его, то можете найти и другие инструменты, которые выполняют ту же работу.

3. Темизация UI

Одной из стандартных практик темизации UI для веб-приложений является использование UI-фреймворка, например Material, Bootstrap (или конкретной реализации, такой как NGX Bootstrap) и т. д. Эти фреймворки предоставляют стандартные UI-элементы, стили и возможность настройки тем. В микрофронтендах важно поддерживать постоянство UI-компонентов для согласованности общей темы приложения.

Поэтому, если вы используете подход с распределенными репозиториями, рекомендуется экспортировать темы и стандартные UI-элементы в приватную библиотеку NPM с CSS, совместно используемым в микрофронтендах. Для этой же цели можно использовать Azure DevOps Artifacts.

4. DevOps

Использование правильных инструментов и практик в DevOps покажет мгновенные результаты. Кроме того, в этой области есть множество инструментов и методов, которые нужно выбирать в зависимости от ваших базовых технологий и платформ. В этой статье я затрону лишь аспекты автоматизации CI/CD, качества кода, телеметрии и мониторинга для микрофронтендов.

Автоматизация CI/CD

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

В контексте микрофронтендов необходимо настроить автоматизацию для сборки кода и интеграции (в зависимости от выбранного подхода), а также выполнить модульные и интеграционные тесты. Одним из важных шагов при работе с микрофронтендами является проверка работоспособности приложения после развертывания. Вы можете использовать комплексный инструмент автоматизации, такой как Cypress, для написания сценариев автоматизации для проверки функциональности веб-приложения.

Поскольку CI/CD является широко используемой практикой, я не буду выделять какие-либо конкретные инструменты. Вы также можете использовать любые другие средства для автоматизации, чтобы решить проблемы, упомянутые выше.

Качество кода

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

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

Телеметрия и мониторинг

Для микрофронтендов я бы порекомендовал отслеживать поведение самого фронтенда. Эффективным методом будет отслеживание фронтендов как практики, так как по очевидным причинам риск сбоя микрофронтендов выше, чем у одного фронтенда. Один из инструментов, который я мог бы предложить, — это Azure AppInsights с использованием его JavaScript SDK для трассировки от фронтенда до всей инфраструктуры бэкенда. Лучше всего, если ваш бэкенд также использует .NET.

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

Заключение

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

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

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

---

Перевод статьи