Что такое микрофронтенд?

Он расширяет концепции микросервисов до внешнего интерфейса. Текущая тенденция заключается в создании многофункционального и мощного браузерного приложения, также известного как одностраничное приложение, которое находится поверх архитектуры микросервисов. Со временем внешний слой, часто разрабатываемый отдельной командой, разрастается, и его становится сложнее поддерживать.

Какую проблему пытается решить?

  • Микрофронтенды — это хороший способ разбить ваш интерфейс на более мелкие части, упрощающие разработку и развертывание.
  • Позволяет нескольким командам вносить свой вклад в приложение, не оказывая негативного влияния на другие команды.
  • Micro Frontends также может ускорить время развертывания и сократить время простоя для пользователей, поскольку в любой момент времени обновляются только части приложения.
  • Это упрощение позволяет выполнять более частые сборки.

Плюсы микро-фронтенда

  • Дополнительные обновления
  • Простая, компактная, несвязанная кодовая база
  • Независимое развертывание
  • Автономные команды
  • Будьте технологически независимы
  • Изолировать командный код
  • Более масштабируемый
  • Возможность обновлять, обновлять или даже переписывать части внешнего интерфейса более инкрементально, чем это было возможно ранее.

Диаграмма микроинтерфейса

Различные фреймворки для каждого компонента

Одна общая структура для всех

Преимущества по сравнению с монолитным подходом

Отдельные команды для Frontend, Backend

Отдельные команды на основе компонентов

Преимущества:

  • Каждая команда кроссфункциональна (они могут работать как над фронтендом, так и над бэкендом)
  • Решает вопросы «Конфликтующих приоритетов»
  • Улучшает коммуникацию и качество
  • Обеспечивает постоянную сосредоточенность на клиентском опыте
  • Итерация быстро
  • Улучшает выравнивание и использование ресурсов.
  • Приводит к большим инновациям.

Как это настроить?

ВАРИАНТ 1: гибридный подход

Использует одно приложение-контейнер, составляющее каждый микроинтерфейс в виде пакета npm.

ВАРИАНТ 2: Настоящий микроинтерфейс

Размещает каждый микро-интерфейс отдельно (аналогично страницам на веб-сайте), где каждый знает URL-адрес (точки интеграции) с параметрами для перехода к другому.

Плюсы и минусы гибридного подхода

Плюсы:

• Простота реализации: просто переместите код в отдельный репозиторий.

• Простота переключения на существующий монолитный интерфейс.

Минусы:

  • Все приложение должно быть повторно развернуто для любых изменений.

Как эта настройка?

  • Весь пользовательский интерфейс работает на одном порту.
  • При обновлении компонентов вам просто нужно обновить версию компонента в файле package.json.
  • Затем все приложение придется перестраивать, повторно тестировать и каждый раз повторно развертывать даже для небольших изменений.

Что входит в пакет NPM?

Входит в пакет NPM:

  • расстояние
  • пакет.json
  • README (необязательно)

НЕ включено в пакет NPM:

  • Тесты
  • Node_Modules
  • Мок-серверы
  • Светильники
  • Все, что не указано на скриншоте выше

Плюсы и минусы True Micro Frontend

Плюсы:

  • Только компоненты, которые были изменены, должны быть повторно развернуты.
  • Развертывание выполняется быстрее и проще.

Минусы:

  • Больше процессов и портов для мониторинга.

Как эта настройка?

Здесь мы передаем URL и порт, компонент работает как переменная env.

Затем используйте компонент Micro Frontend для рендеринга этого компонента на экране.

Затем добавьте новый маршрут при добавлении нового компонента.

Если мы обновляем один компонент, необходимо перестроить, протестировать и развернуть только этот компонент.

Примечания по оптимизации

  • Вам, вероятно, придется внести изменения в то, как приложение связано.

Как работает CI/CD?

  • Каждый компонент отвечает за свой конвейер.
  • Каждый из них должен собираться, запускать тесты и развертываться независимо от всех остальных компонентов.
  • Каждый компонент должен иметь возможность запускаться независимо.
  • Для гибридного подхода необходимо отправить новую версию в NPM.
  • Для True Micro Frontend он должен быть собран и развернут на сервере на своем порту.

Пакеты общих утилит

  • Предоставляет общий способ отображения элементов пользовательского интерфейса, таких как таблицы, формы, диаграммы и т. д.
  • Убедитесь, что компоненты выглядят и действуют одинаково во всем приложении.
  • Ускоряет разработку
  • Улучшает сотрудничество между командами

Распространенные ошибки

  • Слишком тонкое деление микрофронтендов, без учета команд, функций или пользовательского опыта приложения.
  • Не определяя микроинтерфейсы, которые мы ожидали создать заранее.
  • Выбор фреймворка, который не предназначен для поддержки архитектуры микроинтерфейса.
  • Переключение функций из старого приложения в новое по мере необходимости для их изменения вместо запланированного и организованного обновления приложения.
  • Продолжать, не имея плана, как структурировать наши общие библиотеки или определить, что мы должны или не должны делиться между микроинтерфейсами.
  • Разделение приложения на большее количество команд, чем у вас есть персонал.

Опасения по поводу микро-фронтендов

1. Делитесь пакетами, чтобы пакеты не были огромными

  • В гибридном подходе, пока пакеты используют одни и те же зависимости, это не должно увеличивать размер сборки.
  • В True Micro Frontend каждый компонент создается отдельно и имеет свои собственные зависимости.
  • Различные версии одного и того же пакета могут привести к нескольким загрузкам.

Webpack Analyzer — хороший инструмент для просмотра размеров пакетов.

2. Обмен данными между микро-интерфейсами

Состояние приложения без общего доступа

Вам нужен общий слой API, который может кэшировать объекты API. Мы поняли, что большая часть состояния, которое необходимо разделить между дочерними приложениями, — это просто данные API. Состояние пользовательского интерфейса, которого нет в API, используется гораздо реже.

Таким образом, использование библиотеки ajax позволяет дочерним приложениям извлекать данные с сервера, как обычно, но иногда данные на самом деле кэшируются, и запрос ajax на самом деле не выполняется. Таким образом, дочерним приложениям даже не нужно знать, извлекает ли какое-либо другое дочернее приложение те же данные, они просто делают запрос API, как обычно, и эта библиотека ajax позаботится о том, чтобы не делать слишком много запросов ajax к одной и той же конечной точке.

Это решает удивительно высокий процент наших потребностей в обмене данными.

3. Общий стиль

  • Необходимо предоставить общее руководство по стилю, чтобы каждая команда знала о правилах стиля.
  • Пакет Common utils с часто используемыми компонентами значительно улучшает единообразие стилей.

4. Совместное использование общих компонентов

  • Делается это путем создания стилизованных пакетов и отправки их в NPM.
  • Вы должны создавать часто используемые компоненты, такие как таблицы, диаграммы, формы