Вот некоторые из вопросов, которые я получил после своей презентации «Производительность микроинтерфейсов и централизованное кэширование данных» на React Advanced London 2021.
Используются ли Micro-Frontend в основном для крупных организаций и когда несколько команд работают над одной и той же страницей/сайтом, или есть ли какие-то преимущества для небольших команд и разработчиков-одиночек?
Верно, Микро-интерфейсы — это решение организационных проблем. Если у вас нет этой проблемы, то вам, вероятно, не нужны микро-интерфейсы. Они полезны, когда вы сталкиваетесь с проблемами масштабирования, и ваши команды выросли до такой степени, что у вас начинают возникать трения, а развертывание в рабочей среде стало болезненным и медленным.
Для небольших команд могут быть некоторые преимущества, например, если вы организуете свое приложение так, чтобы каждый разработчик владел определенной частью пользовательского интерфейса и развертывал ее независимо. Я не думаю, что у индивидуальных разработчиков есть какие-то преимущества, потому что это добавит ненужной сложности в небольшой проект.
Как вы делитесь глобальным состоянием?
Ответ: нет. Глобальное состояние может вызвать связь между микроинтерфейсами и добавить центральную зависимость, которая может блокировать или останавливать независимые развертывания. Лучшая рекомендация при работе с Micro-Frontends — любой ценой избегать связывания, потому что иначе вы можете получить распределенный монолит и не иметь никаких преимуществ Micro-Frontends.
Теперь, как вы общаетесь между ними? Суть в том, чтобы сообщения были небольшими и сведены к минимуму, уважали системные границы и имели надежные контракты, гарантирующие инкапсуляцию ваших микроинтерфейсов. Хорошим примером этого является использование модели Pub/Sub и postMessage() API.
Как вы поддерживаете стиль написания кода и соглашения для нескольких микро-интерфейсов и команд, работающих над ними?
Люди думают, что Micro-Frontends плохи для согласованности, однако это не проблема, связанная с этим архитектурным шаблоном; это организационная проблема, и поэтому ваша компания и команды несут ответственность за соблюдение стандартов кодирования и единообразие стиля путем внедрения чего-то вроде системы дизайна. Micro-Frontends могут быть полезны для согласованности, позволяя вам повторно использовать определенные части приложения, такие как верхний и нижний колонтитулы.
Как вы делитесь общими компонентами? Вы создаете их как микроинтерфейсы или создаете библиотеку компонентов и используете ее как обычную зависимость npm?
Я бы порекомендовал библиотеку компонентов, однако ключом к тому, чтобы она хорошо работала с Micro-Frontends, является наличие четко определенных атомарных компонентов вместо больших частей пользовательского интерфейса. Кроме того, важно, чтобы библиотека была стабильной (не в активной разработке), чтобы избежать связывания. Если вы постоянно вносите изменения в базовые компоненты, все ваши микроинтерфейсы должны будут потреблять эти обновления, что может создать узкое место и замедлить независимое развертывание.
Как обеспечить одновременное обновление всех команд до последней версии общей зависимости?
Если это зависимость, то вы просто следуете обычному процессу сообщения об обновлении своим потребителям, и они должны будут установить и развернуть свои кодовые базы, чтобы отразить последние изменения.
Если вы хотите обновить микро-интерфейс и хотите, чтобы все ваши пользователи использовали одну и ту же версию, например, если вы хотите, чтобы они использовали одну и ту же версию верхнего или нижнего колонтитула, вы можете использовать два разных подхода.
Первый — это «вечнозеленый» подход, при котором все ваши потребители всегда указывают на последнюю версию, как только она публикуется.
Второй подход — это управляемый подход, при котором вы публикуете свой микро-интерфейс и следуете правилам семантического управления версиями, чтобы потребители могли выбирать, какую версию использовать; Отличие этого подхода от стандартной зависимости npm заключается в том, что вы можете начать использовать новую версию во время выполнения без необходимости устанавливать и развертывать новую версию приложения, которое ее использует.
