Получите максимальную пользу от Micro Frontends, избегая этих ошибок
Micro Frontends может либо сделать ваши приложения гибкими и надежными, либо стать накладными и препятствовать развитию вашего проекта.
И есть много практик, которые могут ввести в заблуждение любого читателя, который только начинает работать с Micro Frontend.
В этой статье я рассмотрю некоторые из этих распространенных ошибок, чтобы вы по возможности их избегали.
1. Неправильное разделение приложения
Многие разработчики часто неправильно понимают идею Micro Frontends и попадают в затруднительное положение.
Чтобы использовать эту технику, мы должны разбить наш монолитный интерфейс (противоположный Micro Frontend) на более мелкие, управляемые части. Но мы должны быть осторожны, чтобы не разделить его слишком мелко.
Вот некоторые из наиболее часто встречающихся проблем, которые могут возникнуть из-за плохого разделения.
- Увеличение количества функций / кода, которые должны быть «совместно использованы» командами Micro Frontend.
- Трудно отслеживать «общие» компоненты.
- Зависимости между функциями / улучшениями в командах Micro Frontend, которые могут отрицательно повлиять на ход разработки.
- Сложнее обновлять, тестировать и развертывать компонент по отдельности.
В конечном итоге это потребует объединения всех компонентов вместе или улучшения координации между командами, и мы вернемся к монолитной архитектуре в кратчайшие сроки!
В результате мы упускаем все преимущества, ожидаемые от Micro Frontend, и в конечном итоге получаем много накладных расходов в ходе реализации проекта.
Какое решение?
Есть два решения этой проблемы.
Вертикальные управляемые срезы (традиционные)
Одно из решений - разделить команды вокруг вертикальных управляемых фрагментов функциональности, а не технических возможностей.
Это обеспечит автономным командам непрерывное владение своими компонентами, что позволит ускорить, масштабировать и повысить эффективность процесса разработки, как и ожидалось.
Независимые компоненты (современные)
Независимые компоненты - довольно новое понятие в веб-разработке, и поэтому их часто неправильно понимают.
Основная идея такова -
Мы используем технологии, разработанные для монолитных проектов, для создания приложений и сервисов, структурированных с помощью компонентов.
Вашей системе управления версиями все равно, будет ли она версией компонента, полного проекта или рецепта супа с лапшой. Ваши инструменты разработки и рабочие процессы сборки - все предполагают полный проект (вот почему, например, Storybook так широко используется - нам нужен способ рендеринга и тестирования компонентов вне контекста конкретного проекта).
Bit меняет все это с помощью компонентов, которые можно разрабатывать и составлять вместе в едином рабочем пространстве, при этом оставаясь полностью независимыми. Они разрабатываются независимо и независимо поддерживают версии (в отличие от вашего традиционного VSC, Bit понимает компоненты).
Поскольку Bit - это независимые компоненты, это очевидный выбор для любой микроархитектуры.
2. Нет дизайн-системы
Когда мы разрабатываем приложение путем интеграции набора компонентов, очень важно иметь четко определенную, единую систему проектирования, реализованную для всех компонентов.
Отсутствие дизайн-системы приводит к нескольким неизбежным проблемам.
1. Дублирование кода из-за ограниченной возможности обнаружения:
Разделение кода на разные команды снизит обнаруживаемость кода. Если дизайн-система заранее не спланирована правильно, каждая команда в конечном итоге будет дублировать одни и те же функции в разных компонентах приложения.
Накладные расходы, возникающие из-за дублирования кода:
- Время будет потрачено на повторную реализацию существующих компонентов.
- Повышает риск пропуска экземпляра или неправильного понимания разницы между двумя похожими компонентами.
- Изменение дизайна конкретного компонента должно быть изменено в более разных местах в нескольких командах.
- Сложнее отслеживать и исправлять ошибки.
2. Несоответствие:
Когда команды не достигают согласия по дизайну каждого компонента, пользователь может столкнуться с несогласованностью в разных частях приложения.
Обновление конкретного элемента должно быть реализовано в каждом используемом компоненте. В результате высока вероятность того, что мы не сможем обновить некоторые части, что снова приведет к несоответствиям в пользовательском интерфейсе.
3. Сложнее отслеживать обмен данными между Micro Frontend:
В приложении Micro Frontends необходимо взаимодействовать друг с другом, чтобы изменять, обновлять или запускать действие в части приложения.
Без реализации четких основных правил для интерфейсов для взаимодействия эти соединения будет труднее отслеживать и поддерживать по мере роста приложения.
Поэтому перед тем, как приступить к внедрению Micro Frontends, лучше разработать правильную систему проектирования, которая обеспечит автономность кодовых баз и команд, чтобы приложение не было беспорядочным.
3. Плохие методы совместного использования кода
Когда несколько команд работают над разными частями внешнего интерфейса, некоторые компоненты обязательно появятся в нескольких микро-интерфейсах. Лучший способ реализовать эти общие компоненты - повторно использовать их, разделяя компоненты между командами, вместо того, чтобы дублировать код путем повторной реализации.
Однако, если вы не используете Monorepo, совместное использование этих компонентов как пакетов NPM может создать множество проблем.
- Трудно проверить совместимость общего компонента с остальными компонентами в конкретном Micro Frontend.
- Трудно отслеживать версии общих компонентов, используемых в разных Micro Frontend. Работа с разными версиями в системе может вызвать конфликты и ошибки в приложении в целом.
- Трудно интегрировать новую версию (обновление) разделяемого компонента.
- Трудно управлять жизненным циклом CI / CD для каждого компонента.
Решение с Bit
Таких неприятностей легко избежать, если использовать не что иное, как Bit. Каждый независимый компонент, разработанный с помощью Bit, также публикуется как стандартный пакет Node с автоматически генерируемым package.json.
С Bit нам не нужно отслеживать зависимости каждого компонента вручную, потому что он автоматически создает граф зависимостей для каждого компонента, включая используемую версию, на основе нашего исходного кода.
Поскольку все версии компонента доступны на платформе Bit, команды могут обновлять общий компонент в своей рабочей области до новой версии в своем собственном темпе. Таким образом, каждая команда может выпускать изменения и обновления независимо и непрерывно.
4. Неправильно Определение основы и методов интеграции
Еще одна распространенная ошибка, связанная с Micro Frontends, - это думать о том, как вы закладываете основу для проекта.
Тщательно подумайте о структуре вашего приложения и возможностях ваших команд при принятии решения о том, как вы разделите приложение и как вы его интегрируете в конце.
Выбор фонда
Иногда мы получаем неправильную основу или снижаем гибкость разработки.
- Использование оболочки приложения в качестве основы - один из подходов, которые мы обычно используем с Micro Frontends. При подходе к оболочке существует оболочка приложения, которая составляет различные интерфейсы Micro Frontend. Если вы следуете этому подходу, вы должны установить правильные способы связи, определив правильное разделение, обычно с помощью параметров URL.
- Разделение на несколько микроприложений - еще один подход к разделению микроприложений. Однако совместное использование кода и оптимизация пакетов могут стать серьезным узким местом без надлежащего управления.
- Использование независимых компонентов - это еще один подход, который однозначно решает проблему. У него есть кривая обучения, понимание концепции и использование таких платформ, как Bit, для управления совместным использованием компонентов.
Выбор метода интеграции
Micro Frontends можно интегрировать как во время сборки, так и во время выполнения. Обычно мы выбираем интеграцию времени выполнения вместо времени сборки по следующим причинам.
- Интеграция во время сборки может вызвать проблемы с синхронизацией из-за управления версиями компонентов.
- При интеграции во время сборки вам необходимо перекомпилировать и выпустить все приложение, чтобы внести изменения в один компонент.
- Окончательный размер пакета может увеличиться, если отложенная загрузка не настроена должным образом.
Итак, вам придется подумать об этих проблемах и использовать такие платформы, как Bit, чтобы справиться с ними.
5. Попытка отразить микросервисы
Уже не секрет, что микросервисы влияют на Micro Frontends. Однако между этими двумя есть существенные различия, о которых нам нужно знать.
- Микросервисы распространяются и используют разные языки программирования, инструменты, технологии и т. Д., Что лучше всего подходит для обеспечения устойчивости. Однако это не совсем так с Micro Frontends, где мы должны добиться согласованности, которая требует аналогичных технологий, инструментов и практик.
- Микросервисы не поощряют совместное использование, но способствуют большей автономии. Однако с Micro Frontends повторное использование важно для согласованности и уменьшения размеров пакетов, которые влияют на производительность.
- Микросервисы определяют отдельное управление состоянием, хранилище для изоляции. С Micro Frontends, хотя мы можем определить некоторый уровень автономии, в конечном итоге они станут единым приложением для конечных пользователей. Таким образом, изолировать невозможно, поскольку Micro Frontend должны зависеть от общих ресурсов в браузере, таких как хранилище браузера, API истории, параметры URL и т. Д.
Заключение
При правильной реализации архитектура Micro Frontend является отличным методом для установления четких границ между командами разработчиков, обеспечивая при этом правильный уровень взаимодействия и сплоченности.
Не забывайте внимательно понимать возможности и масштабы вашей команды и составить четкий план дизайна, прежде чем приступать к выполнению!
Я надеюсь, что информация, представленная в этой статье, избавит вас от неприятностей и проведет вас через беспроблемный и приятный процесс разработки.
