Сначала давайте поговорим о том, что такое микро-интерфейсы и как они полезны в различных сценариях.
Micro Frontend в основном применяется к концепции архитектуры Micro Services backend для интерфейсных приложений. Это означает разделение веб-приложения на отдельные изолированные единицы, чтобы разные независимые команды могли работать с этими модулями со своим собственным набором правил и структур, а позже эти изолированные модули могут входить в единую оболочку, чтобы выглядеть как одно приложение и могли работать как единое приложение для пользователя. Например, приложение электронной коммерции может иметь корзину, продукты, заказы, выставление счетов в качестве некоторых из микро-интерфейсов.
Если вы внимательно прочитаете приведенное выше объяснение, вы сможете перечислить следующие преимущества архитектуры микро-интерфейса, которые аналогичны архитектуре микросервисов.
- Изолированные подразделения и независимые команды.
- Свобода выбора различной технологии для каждого изолированного устройства.
- Раздельное развертывание для каждого подразделения, поэтому нет необходимости в повторном развертывании всех подразделений.
- Разделение репозитория кода, что приводит к большему контролю.
Может быть больше преимуществ, но они кажутся основными преимуществами использования архитектуры внешнего интерфейса Micro.
Хотя эти преимущества привлекают многих и могут показаться идеальным решением для любого типа приложений. Это не так, и для этого нам нужно взглянуть на некоторые из подводных камней, или вы можете назвать их сценариями, в которых микро-интерфейс не может показаться идеальным решением.
Давайте рассмотрим эти подводные камни по очереди.
- Необходимость одинакового пользовательского интерфейса для всех микро-интерфейсов
Поскольку эти изолированные модули работают под одним приложением-оболочкой, чтобы выглядеть как одно интегрированное приложение, они должны следовать аналогичным рекомендациям и шаблону UX. В случае, когда другому приложению может потребоваться другой внешний вид в зависимости от его использования. Микро-интерфейс может показаться не подходящим решением.
2. Использование различных стеков технологий
В серверных приложениях это может не быть проблемой. Но на клиенте главное внимание уделяется скорости запуска и производительности приложения. Потому что мы не хотим, чтобы пользователь долго ждал загрузки страницы. Использование другой инфраструктуры потребует, чтобы каждый микро-интерфейс на стороне клиента загружал свой собственный набор зависимостей и структуру на стороне клиента, что может замедлить работу приложения.
Хотя микро-интерфейс позволяет нам использовать разные технологические стеки, мы должны быть очень осторожны при принятии решения, потому что это напрямую скажется на производительности. Эта проблема касается не только выбора разных фреймворков, но и выбора разных версий одной и той же зависимости в двух микро-интерфейсах. Вот почему рекомендуется использовать один и тот же фреймворк и одну и ту же версию основных зависимостей в разных микро-интерфейсных приложениях.
3. Изолированные блоки
Если вы посмотрите на объяснение выше, микро-фронтенды говорят об отдельных единицах. Но в реальных приложениях мы могли бы захотеть настроить связь между этими изолированными модулями, которая создаст своего рода связь между микроволнами. Если это сообщение требуется, у нас есть ограниченные возможности для этого. Но мы должны избегать такого рода общения до тех пор, пока не станет возможным создать какую-либо связь между микро-интерфейсами. Потому что создание такой связи отнимет часть той независимости, о которой мы говорили как о преимуществе микро-интерфейсов.
4. Независимые команды
Потому что в идеальном сценарии каждый микро-интерфейс будет управляться независимыми командами. Каждая команда может установить свои собственные принципы проектирования и руководящие принципы. Они могут выбрать разные технологии и техники для реализации интерфейса. Вот почему существует потребность в общих рекомендациях и принципах проектирования для этих независимых команд, чтобы избежать повторного изобретения колеса для аналогичных задач. Это также поможет решить ловушку №2.
Хотя важно понимать преимущества использования определенной архитектуры, но также важно понимать ее подводные камни, чтобы принять лучшее решение при выборе конкретной архитектуры.
Читая о преимуществах микро-интерфейсов, может показаться, что монолитная архитектура не является правильной архитектурой для создания веб-приложений. Но после того, как вы поймете подводные камни и проанализируете их в сравнении с требованиями ваших приложений, вы все равно можете выбрать монолитную архитектуру. Если говорить о производительности, то теперь интерфейсные фреймворки предоставляют уже готовую поддержку различных стратегий, которые можно использовать для достижения этой цели. Для более подробного изучения микро-интерфейсов вы можете перейти здесь.
