Недавно я писал о пяти причинах, по которым стоит внедрить архитектуру микрофронтенда. Конечно, во всем есть плюсы и минусы. Микрофронтенды — это свежий архитектурный подход, который, вероятно, представляет собой будущее
В этой статье вы узнаете самые важные уроки, которые мы с моей командой усвоили при использовании микроинтерфейсов. За два года мы выявили много проблем с этой архитектурой и сделали столько же ошибок. Итак, пришло время поделиться ими, чтобы помочь вам справиться с ними или избежать их.
Давайте сначала вспомним, что такое архитектура микрофронтенда, а затем углубимся в их подводные камни и как избежать каждого из них.
Кратко о микрофронтендах
Мартин Фаулер определяет микроинтерфейсный подход к разработке следующим образом:
архитектурный стиль, в котором независимые интерфейсные приложения объединяются в единое целое.
Применительно к
Это означает, что мы узнали не только о хороших вещах, связанных с микроинтерфейсами, но и об их основных недостатках. Давайте теперь углубимся в них и посмотрим, что мы должны были сделать, чтобы избежать или решить их.
1. Избыточные зависимости
Каждое микроинтерфейсное приложение по определению не зависит от других. Другими словами, микроинтерфейсная архитектура включает более одного внешнего приложения, которое должно работать без других. Для этого у каждого из них есть свои зависимости. Итак, глядя в целом, вы теряете преимущества использования менеджера пакетов. На самом деле все ваше приложение, скорее всего, будет состоять из множества версий одних и тех же библиотек, разбросанных по микроинтерфейсам.
Это, несомненно, проблема, потому что это делает ваше
Как решить эту проблему
Возможное решение включает три шага.
Как описано в исходном сообщении в блоге Мартина Фаулера, из которого исходит эта идея, совместное использование зависимостей между приложениями создает множество препятствий и не может считаться легкой задачей. Так что имейте это в виду, когда вы пытаетесь достичь этой цели.
2. Конфликтующие и перекрывающиеся стили
Опять же, технология и независимость команды — это здорово, но это также может привести к некоторым проблемам. Особенно это касается стилей. На самом деле у каждого микрофронтенда не может быть своего собственного стиля с точки зрения бизнеса. Это потому, что вы определенно не хотите, чтобы ваши приложения выглядели состоящими из множества исправлений. Все должно выглядеть последовательно, как с точки зрения стиля, пользовательского интерфейса, так и UX.
Другая проблема, возникающая
Эти проблемы могут негативно сказаться на репутации вашего бренда. Кроме того, конечные пользователи будут платить за эти несоответствия, особенно с точки зрения пользовательского интерфейса.
Как решить эту проблему
Единственное возможное решение, когда дело доходит до UI и UX, — убедиться, что каждая команда общается с другой и думает об одном и том же результате. Кроме того, здесь может помочь добавление стилизованных компонентов в вышеупомянутый общий проект микроинтерфейса. Тем не менее, это сделало бы каждое приложение микроинтерфейса зависимым от него, и, как следствие, это нарушило бы базовую независимость. Но, по крайней мере, это не позволит вашему приложению в целом выглядеть неоднородным.
Если вы хотите избежать перекрытия CSS, решение включает в себя добавление идентификатора в контейнер внешнего интерфейса
3. Низкая производительность
Если на одной странице запущено более одного внешнего приложения JavaScript, это приведет к замедлению работы всего приложения. Это связано с тем, что для каждого экземпляра платформы требуются ресурсы с точки зрения ЦП, ОЗУ и пропускной способности сети.
Также имейте в виду, что при тестировании своего микрофронтенда изолированно от других вы можете этого не заметить. Проблемы начинаются, когда одновременно работает более одного экземпляра фреймворка. Это связано с тем, что, если они выполняются независимо, им не нужно совместно использовать ресурсы базовой машины, как это будет необходимо при развертывании.
Как решить эту проблему
Идея решения этой проблемы состоит в том, чтобы укрепить командную коммуникацию, чтобы избежать одних и тех же звонков и уточнений. Затем сохраните их результат в месте, к которому имеет доступ каждый
Кроме того, когда дело доходит до производительности, вы должны тестировать приложение со всеми его
4. Связь между интерфейсами
Первоначально вам не нужно будет заставлять свои микрофронтенды общаться, за исключением редких случаев. Это может ввести вас в заблуждение, думая, что так будет всегда. Кроме того, хотя архитектурный шаблон микроинтерфейса ориентирован на независимость, он противопоставляется общению.
Когда приложение в целом растет, обеспечение возможности взаимодействия ваших микроинтерфейсов друг с другом без особых усилий, вероятно, станет приоритетом. Прежде всего, если вы хотите повторять одни и те же операции снова и снова, особенно если они не являются идемпотентными.
Кроме того, связь необходима для достижения более высокой производительности, как объяснялось выше. Например, вы не хотите, чтобы ваше приложение дважды выполняло один и тот же вызов API для извлечения одних и тех же данных и без необходимости замедляло работу вашего сервера.
Как решить эту проблему
Решение состоит в том, чтобы реализовать собственный уровень обмена сообщениями на основе общего состояния, хранящегося в файле cookie или localStorage, или на определенных пользователем событиях. Как вы можете себе представить, реализация этого требует затрат и может быстро стать сложной и громоздкой в управлении. Кроме того, примите во внимание, что связь вводит накладные расходы. Таким образом, вы должны быть уверены,
5. Проблемы коммуникации между командами
Общение в большой команде может быть проблемой, но нет ничего хуже, чем общение между несколькими командами. Это связано с тем, что наличие нескольких команд, работающих над разными кодовыми базами, означает, что поиск повторно используемых функций, функций и утилит становится сложнее. Это плохо с точки зрения возможности обнаружения кода и, следовательно, повторного использования. Другими словами, вы легко можете столкнуться с дублированием реализации одних и тех же компонентов в разных микроинтерфейсах.
Как решить эту проблему
Решение состоит в том, чтобы поддерживать логику общения между командами с самого начала. Как упоминалось выше, это предполагает наличие одного проекта с многократно используемыми ресурсами для каждой принятой технологии. Но наличие такого проекта без поддержания его в актуальном состоянии сделало бы его бесполезным.
Итак, вы должны разрешить каждой команде добавлять к ней компоненты и библиотеки. Кроме того, наличие команды, занимающейся этим, может упростить весь процесс. На самом деле, независимой и изолированной команде может быть непросто понять, какие элементы будут общими для более чем одного микроинтерфейса.
Более того, не думайте о технологической независимости как о нескольких изолированных командах. Напротив, наличие команд, общающихся друг с другом и постоянно обновляемых, имеет решающее значение для успеха проекта. Таким образом, развитие культуры общения должно быть одним из ключевых элементов при внедрении архитектуры микроинтерфейса.
Заключение
В этой статье мы рассмотрели пять самых больших подводных камней архитектурного подхода к микроинтерфейсу, опираясь на опыт, который моя команда накопила, ежедневно работая с ним в течение двух лет. Хотя подход с микроинтерфейсом позволяет разработчикам разделить интерфейсное приложение на более мелкие независимые части, это не означает, что каждая команда также должна быть изолирована. Напротив, совместное использование решений, компонентов, ресурсов и знаний является ключом к успеху.
К сожалению, мы не знали этого как команда. Таким образом, мы были вынуждены отказаться от нашего путешествия по микрофронтенду. Но мы многому научились из этого приключения, и я надеюсь, что было полезно рассказать об основных причинах, которые привели нас к неудаче, и о том, как их избежать или противодействовать им.
