Взглянем на потенциальные недостатки использования Microfrontend и когда нет смысла их использовать.
Разработка веб-интерфейса стала сложной… мимолетного осознания того, что нужно объединять HTML, CSS и JavaScript, уже недостаточно, чтобы продвинуться в мире разработки современных веб-приложений (React / Angular / Vue и т. Д.).
Концепция Microfrontends представляет собой способ разделения огромного монолитного пользовательского интерфейса на более мелкие и более управляемые части.
Подумайте о микросервисах как о веб-интерфейсе.
Однако это не серебряная пуля - в этой статье, посвященной кирпичу, я собираюсь рассмотреть, когда вам не следует рассматривать микрофронтенды для своего проекта.
Я опубликовал множество статей о Microfrontends как архитектурном шаблоне проектирования и обсуждал многие преимущества по сравнению с монолитным пользовательским интерфейсом.
Я получил много интересных отзывов о Microfrontend как о шаблоне проектирования. Отзывы были в основном положительными, поскольку многие из них касались проблем, которые Microfrontends пытается решить.
Однако, как справедливо отметили некоторые, бывают случаи, когда нет смысла применять такой шаблон архитектурного проектирования - давайте рассмотрим некоторые из них в этой статье.
Разве микрофронтенды не усложнят сборку?
Сложность - не новая проблема в разработке пользовательского интерфейса.
Возьмем, к примеру, NPM (менеджер пакетов JavaScript) ... типичный проект Python будет иметь несколько зависимостей, Angular (структура пользовательского интерфейса) из коробки имеет более 1300!
Чтобы создать проект пользовательского интерфейса, вы просто должны иметь в своем распоряжении множество инструментов для извлечения, рендеринга, тестирования, обновления, сборки, оптимизации и всего остального.
Введение Microfrontends поднимает эту сложность на совершенно новый уровень, теперь вам нужно управлять несколькими экземплярами каждого, верно?
К сожалению, это правда, но есть способы уменьшить такую сложность.
На мой взгляд, вы просто не можете работать в Microfrontends без наличия надежного процесса CI (непрерывная интеграция) / CD (непрерывная доставка).
Поскольку ваше приложение масштабируется на десятки или потенциально сотни небольших интерфейсов (каждый со своим собственным процессом сборки), вам нужно будет стандартизировать некоторые инструменты вокруг них, иначе вы попадете в целый мир боли !
Придерживаться одной или нескольких структур пользовательского интерфейса (например, Angular / React) может быть хорошим началом, поэтому все ваши процессы сборки используют аналогичные шаги.
Инструменты контейнеризации, такие как Docker / Kubernetes, также отлично справляются с этой задачей.
Я остановлюсь на этой мысли и обещаю дополнить ее статьей о том, как выглядит надежный процесс CI / CD для Microfrontends.
Я работаю над небольшим приложением, которое вряд ли будет расти, имеет ли смысл использовать микрофронтенды?
Короче говоря, ответ здесь - категорический нет.
Я часто нахожу, что команды, успешно применяющие шаблон архитектурного проектирования (например, Microfrontends), естественным образом тянутся к нему, решительно отождествляя себя с проблемами, которые он, как утверждается, решает.
Давайте посмотрим на качества микрофронтендов (похожих на микросервисы):
- Легко обслуживается и тестируется
- Слабо связанный
- Независимо развертываемый
- Организован вокруг бизнес-возможностей
Чтобы успешно внедрить Microfrontends, ваше приложение должно быть улучшено большинством, если не всеми из них.
Например, если вы разрабатываете приложение в одиночку, без каких-либо других зависимостей, вам не нужно беспокоиться о том, что оно будет слабо связано или независимо развертывается, так что это не битва, в которой вам нужно сражаться, сохраните ваша энергия и энтузиазм в другом!
Разве компоненты / библиотеки не будут дублироваться через микрофронтенды, увеличивая размер файла и отрицательно влияя на производительность?
В сценарии, когда ваше приложение потенциально может состоять из нескольких экземпляров одной или нескольких платформ, могут быть компоненты и библиотеки, дублированные во всем вашем приложении, особенно если инкапсуляция или слабая связь является фактором.
Возьмем, к примеру, Angular, он уже идет в комплекте с библиотекой RxJS. Если у вас есть 5 Microfrontend на основе Angular, у вас может быть 5 экземпляров RxJS, обслуживаемых вашими пользователями.
Как этого можно избежать, во многом зависит от того, как построено ваше приложение. В этом примере можно отложить загрузку некоторых библиотек и поделиться ими с каждым из ваших микрофонов.
В других случаях вам, возможно, просто придется признать, что это так, и учесть это при принятии любого решения в будущем.
Как мы можем обеспечить согласованность внешнего вида дизайна, если все наши микрофронтенды - это отдельные проекты?
Это одна из самых больших проблем при использовании Microfrontend. Что, если пользователь замечает наличие нескольких проектов под капотом из-за несогласованного дизайна пользовательского интерфейса и / или взаимодействия с пользователем (UX)?
К счастью, есть несколько библиотек, которые помогают улучшить согласованность. Material UI и Bootstrap - два наиболее популярных примера.
Каждый из них обеспечивает единообразный дизайн того, как должны выглядеть и вести себя кнопка, таблица, заголовок и т. Д.
Возможно, вам даже будет иметь смысл начать с одного из них в качестве основы и развивать его для своей компании или приложения.
Как и любое решение, которое мы принимаем при разработке и создании программного обеспечения, в контексте вашего приложения есть свои преимущества и компромиссы. То, что имеет смысл для одного, не обязательно будет иметь смысл для другого.
Если мы располагаем фактами, это делает эти решения обоснованными и с большей вероятностью будут успешными при реализации.
Спасибо, что нашли время прочитать мою статью.
