Состояние микрофронтендов

Одна из наиболее противоречивых тем во фронтенд-разработке — это микрофронтенды. Заслуживают ли они внимания? Стоит ли на самом деле разделять приложение? Нужны ли они вам уже сегодня? А может это просто ещё один повод для консультантов заработать денег?

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

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

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

Главная проблема здесь в том, что эти части всегда потребляются или воспринимаются как одно целое.

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

Есть несколько способов решить эту проблему. Наиболее простой из них заключается в замене модели передачи данных существующих API на HTML-вывод. Перемещение от одного сервиса (представления) к другому было бы просто гиперссылкой. Недостаток этого подхода в том, что, несмотря на работоспособность, в большинстве случаев он определённо не обеспечит желаемого пользовательского опыта.

Эволюция распределённых web-приложений

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

Хорошим вопросом здесь является взаимосвязь микрофронтендов с компонентами и модулями. Получается, что все эти принципы стремятся привнести некую переиспользуемость и ответственность в виде паттерна единицы работы (UoW). Единственное отличие в том, к какому уровню происходит обращение.

Компоненты являются строительными блоками базовой библиотеки UI.
Модули являются строительными блоками соответствующей среды выполнения.
Пакеты являются строительными блоками механизма разрешения зависимостей.
Микрофронтенды являются строительными блоками представленного приложения.

Таким образом, микрофронтенды представляют органы тела. Пакеты —это клетки, модули — молекулы, а компоненты соответствуют атомам.

Почему используют микрофронтенды

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

Микрофронтенды применяются для того, чтобы:

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

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

Возможность создания фул-стек команд

Микрофронтенды могут оказаться очень кстати, когда актуален один или несколько из следующих пунктов:

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

Кто использует микрофронтенды

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

DAZN
Elsevier
entando
Fiverr
Hello Fresh
IKEA
Bit.dev
Microsoft
Open Table
OpenMRS
Otto
SAP
Sixt
Skyscanner
smapiot
Spotify
Starbucks
Thalia
Zalando
ZEISS
… и многие другие!

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

Компании, использующие микрофронтенды (подборка Люка Меццалира)

Список растёт с каждым днём: начиная с консалтинговых компаний, вроде ThoughtWorks или HLC, и заканчивая провайдерами облачных услуг (SaaS), вроде SalesPad или Apptio. Однако ставки на эту технологию также делают и более консервативные компании. В качестве примера можно привести обладателя звания “Hidden Champion 2015” (скрытый чемпион) немецкую компанию Hoffman Group.

Пример Hoffman Group — это отличный случай, демонстрирующий, что микрофронтенды не требуют крупных команд разработчиков, равно как и внутренних ресурсов. Они выбрали эту технологию, в частности, из-за своих взаимодействий с множеством поставщиков услуг.

Пример микрофронтендов с компонентами

Платформа Bit.dev и её маркетинговый сайт построены с использованием компонентов React, которые управляются при помощи… Bit.

Взгляните на эту страницу. Вы можете навести указатель на разные её компоненты и увидеть их “исходные коллекции”. Кликните по имени компонента (сверху), чтобы просмотреть его и даже установить в свой проект.

Эта страница построена из компонентов, разработанных в двух разных базах кода с GitHub: “base-ui” (см. коллекцию на Bit) и “evangelist” (см. коллекцию на Bit).

Коллекция base.ui служит в качестве системы проектирования (также опубликованной с помощью Bit). Компоненты в коллекции evangelist (используется для маркетинговых страниц) задействуют некоторые из компонентов, доступных в base-ui, чтобы поддерживать единый внешний вид UI между различными микрофронтендами.

В этом примере Bit используется и как способ автономного предоставления возможностей, и как способ поддерживания согласованного UI между разными микрофронтендами.

Как создавать микрофронтенды

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

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

Клиентские фреймворки

Для микрофронтендов клиентской стороны существует широкая вариация фреймворков. Некоторые из них также позволяют отображение на стороне сервера.

Композиция клиентской стороны

Такой (или аналогичные) шаблон реализуют следующие фреймворки:

Piral
Open Components
qiankun
Luigi
Frint.js

Серверные фреймворки

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

Композиция серверной стороны

Такой же или аналогичный шаблон реализуют следующие фреймворки:

Mosaic
PuzzleJs
Podium
Micromono

Вспомогательные библиотеки

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

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

Совместное использование зависимостей при помощи карт импорта (Import Maps)

Следующие библиотеки помогают понизить количество рутинного кода:

Module Federation
Siteless
Single SPA
Postal.js
EventBus

Будущее микрофронтендов

В то время как некоторые люди видят объединение вещей с помощью вспомогательных библиотек, подобно модульной федерации (module federation), большинство остается неизменным к своим подходам. Радует, что многие фреймворки позволяют легко писать код, который не приводит к серьёзной зависимости от поставщика. Тем не менее недостаёт общего стандарта, который упростил бы обмен решениями хотя бы в техническом плане.

Ещё одна вещь, которой пока что недостаёт ,— это принятие и более широкое освоение сообществом.

Несмотря на то, что микрофронтенды набирают популярность, большая часть сообщества до сих пор пребывает в сомнениях.

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

Заключение

Доступное количество существующих решений и их пользователей во многих проектах по всему миру посылает мощный сигнал: микрофронтенды готовы к использованию! Я же рекомендую перед началом крупного проекта сначала ознакомиться с различными паттернами и решениями.

Перевод статьи Florian Rappl: The State of Micro Frontends.

Поделиться статьей:

Вернуться к статьям