5 причин перехода к микрофронтенд архитектуре

Независимые команды разработки

Если вы работаете в нескольких командах, организационные накладные расходы становятся значительными. Общение должно происходить хотя бы ежедневно. Согласование, необходимое для управления разработкой и развертыванием, становится невозможным. Благодаря микрофронтендам управление масштабируемостью с точки зрения ресурсов разработки становится намного проще. Как правило, каждая функция может быть разработана независимой командой. Каждая команда может автономно публиковать свой функционал без какого-либо согласования. Некоторые подходы к микрофронтендам требуют, по крайней мере, общей системы сборки или общего уровня (например, reverse proxy). Хотя такие вещи все еще можно решить заранее, они делают все решение более сложным, чтобы его можно было правильно настроить на начальном этапе. Поэтому рекомендуется искать решения, которые уже работают после первоначальной настройки.

Более быстрое время выхода на рынок (TTM, Time To Market)

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

• начать новый проект
• разработать MVP
• зарелизить MVP
• пройтись по MVP (доработать и зарелизить)
• перейти в режим обслуживания

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

Фича флаги (Feature Flags)

Замечательно иметь отдельные микрофронтенды, составляющие вместе одно приложение. Но довольно часто владельцы продуктов хотят выйти за рамки технической композиции: они хотят использовать модульность также и для бизнес-целей. Случалось ли вам когда-нибудь, что определенная функциональность должна быть доступна только определенным пользователям? Функции администратора должны быть доступны только администраторам. Хотя UI не следует использовать в качестве уровня защиты (эти проверки осуществляются на бэкэнде), мы также не хотим показывать вещи, которые нельзя (или не следует) использовать. Следовательно, мы добавим в наш код такие вещи, как:

if (hasFeature('foo')) {
  // ...
}

Это довольно плохой стиль. Наш код теперь полон вещей, которые, скорее всего, изменятся. Что, если foo верно для всех? Что делать, если функция деактивирована для всех? Что, если завтра появится новое условие, изменяющее некоторые части, чтобы также оценить, включена ли переменная bar? Поскольку у нас уже есть надлежащая модульность, довольно просто добавить фича флаги. Все, что нам нужно сделать, это ввести условный рендеринг модуля (или его загрузки) с помощью флагов. Никаких изменений кода на функциональном уровне модуля. Хотя подобные вещи могут работать и в классических монолитах, они требуют дополнительных усилий по реализации. С микрофронтендами архитектура уже полностью к этому готова.

Единая ответственность

Несмотря на то, что микросервисы не являются решением для всего, они преподносятся как таковые. Да, они, безусловно, являются хорошим решением во многих (или даже в большинстве) случаях, но очень часто монолит или другая форма сервис-ориентированной архитектуры может оказаться не менее хорошим решением. Тем не менее, наличие выделенного сервиса (с ответственной за него командой) в бэкенде — хорошее начало. Замена монолита различными микрофронтендами — это отличное продолжение, поскольку можно ввести дополнительное измерение для разделения команд.

Одна из возможностей — начать с фулстэк команд. Таким образом, команда, занимающаяся бэкэнд-модулем (микросервисом), также отвечает за фронтенд (микрофронтенд). Хотя с технической точки зрения сервис и его фронтенд определенно являются двумя разными вещами, с точки зрения бизнеса они связаны или даже являются одним целым. Наличие одной бизнес-возможности или функции от одной ответственной команды, безусловно, является преимуществом. Одна из проблем заключается в том, что типичный сценарий пользователя довольно часто затрагивает несколько бизнес-возможностей. Поэтому рекомендуется использовать фреймворк, который также позволяет динамически использовать компоненты из одного микрофронтенда в другом микрофронтенде. Связь должна быть слабой, чтобы по-прежнему можно было использовать фича флаги.

Свобода технологий

За последние два года фронтенд-технология в значительной степени стабилизировалась. Хотя и появляются новые подходы, например Svelte, которые бросают вызов таким библиотекам как React, но все же серьезных преимуществ они не предлагают. Часто существует несколько подходов и не существует универсального решения. В микрофронтенд приложениях все разные приложения могут работать вместе. Страница, написанная с помощью Angular, может использовать компонент из микрофронтенда React и наоборот. Модальное диалоговое окно для сохранения пользовательских данных может быть написано на Vue, а компонент под ним — на Svelte.

Проблема последовательного пользовательского опыта становится сложной. Возникает много вопросов. Среди наиболее важных из них:

• Мы разделяем только CSS?
• Как насчет поведения?
• Являются ли веб-компоненты решением для этого?

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

Итоги

Микрофронтенды — это не панацея. Они могут помочь и обеспечить ценность, когда обстоятельства благоприятны. Если ни одна из вышеперечисленных причин не имеет для вас никакого значения, велика вероятность, что вам не нужно внедрять микрофронтенд архитектуру.

Client Side Include - CSI (Включение на стороне клиента)

Client Side Include (CSI) является довольно знакомой для фронтенд-разработчиков возможностью, в основном это вызов Ajax. Что выделяет его, так это контент, который возвращает запрос. Тип контента - html/text, похожий на обычный HTML, который мы используем. В этом контексте мы не запрашиваем фрагмент данных, вместо этого мы ожидаем фрагмент HTML.

<body>
  Hello World
  <footer>
    <h-include src="a server address"></h-include>
  </footer>
</body>

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

Server Side Include - SSI (Включение на стороне сервера)

Как видно из названия, включение на стороне сервера (SSI) не происходит на компьютере клиента.

<body>
  Hello World
  <!--#include virtual="/..." -->
</body>

Вместо этого, когда сервер анализирует HTML-файл, он проверяет определенные строки, помеченные #include. Для любых найденных включений он извлечет содержимое и вставит его в это место, прежде чем вернуть окончательный документ. Преимущество SSI заключается в том, что, как правило, серверы работают быстрее по сравнению с клиентским компьютером. Не говоря уже о том, что количество запросов между клиентами и серверами сокращается до 1. Таким образом, обычно мы можем получить время отклика около 1 мс по сравнению с временем отклика 50 мс при вызове API. При этом не стоит злоупотреблять использованием большого количества включений на одной страницу. Для каждого включения серверу необходимо выполнить несколько вызовов и дождаться завершения всех вызовов, прежде чем он сможет агрегировать файл. Это может занять больше времени, чем вы ожидаете, не говоря уже о том, что один из вызовов может завершиться сбоем. Таким образом время отклика может вырасти до 500 мс и больше. Любое время, выходящее за рамки 1 сек, может стать критичным для продакшен сервера. Поэтому разумно использовать SSI только для основного содержимого страницы, а не для каждого декоративного элемента (например счетчик или футер и т.д.). Также можно попробовать комбинировать CSI и SSI. SSI также не новая технология. Во времена, когда существовали только бэкенд-разработчики, каждый фрагмент HTML-шаблона, собранный на сервере, можно было назвать SSI.

Edge Side Include - ESI

Идея включения на Edge Side (на стороне CDN), была предложена еще в 2001 году, но с тех пор она так и не стала общепринятой. Тем не менее, она может решить проблемы SSI. Имейте в виду, что ESI происходит и на сервере.

<body>
  Hello World
  <esi:include src="a server address" />
</body>

С точки зрения использования, это не слишком отличается от включения SSI. Считается, что в некоторых реализациях ESI это улучшает время до первого байта (TTFB). Потому что он может сначала вернуть доступный документ, прежде чем все включения будут скачаны и возвращены. Это похоже на комбинацию CSI и SSI, за исключением того, что все обрабатывается на сервере.

Итоги

Существует множество подходов для реализации микрофронтендов, в том числе CSI, SSI и ESI. Эти подходы могут казаться запутанными, отчасти потому, что разработчики использовали их, не зная терминологии.