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

^[1]

Хотя микрофронтенды окружены множеством ^[2] слухов, нельзя отрицать того, что эта технология с каждым днём становится всё популярнее. Автор статьи, перевод которой мы сегодня публикуем, предлагает поговорить о том, кто пользуется микрофронтендами, о том, почему применяется эта технология, и о том, что может ускорить и упростить работу того, кто решил создать микрофронтенд-приложение.

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

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

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

В то время как бэкенд-системы никогда не используются как некая монолитная сущность, фронтенд — это система, которая напрямую ответственна за то, что называют «пользовательским опытом» (User Experience, UX).

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

Эволюция распределённых веб-приложений: монолит, разделение фронтенда и бэкенда, микросервисы, микрофронтенды

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

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

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

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

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

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

Микрофронтенд-решения, по сути, должны обладать следующими свойствами:

• Отдельные фрагменты интерфейса могут быть разработаны, протестированы и развёрнуты независимо.
• Части интерфейса поддерживают добавление, удаление и замену без необходимости пересборки проекта.
• Разные блоки интерфейса могут быть созданы с использованием различных технологий.

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

Компактные фуллстек-команды разработчиков

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

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

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

Всё больше и больше компаний активно используют микрофронтенды. Вот актуальный список некоторых из таких компаний:

• 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. Один из примеров — немецкая компания Hoffmann Group, которую, пользуясь термином Германа Симона, можно назвать «скрытым чемпионом».

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

Пример построения микрофронтенда, основанного на компонентах

Платформа Bit.dev ^[3], а также её маркетинговый сайт, построены с использованием React-компонентов, управление которыми организовано с помощью этой же платформы.

Взгляните на эту ^[3] страницу. Если поводить по ней мышью, наводя её на разные части страницы, можно увидеть всплывающие подсказки, сообщающие о том, к каким «коллекциям источников» принадлежат эти компоненты. Для того чтобы исследовать компонент, нужно щёлкнуть по его имени (оно выводится над компонентом). Такой компонент можно даже интегрировать в собственный проект.

Сведения о компонентах, выводимые на странице

Эта страница создана из компонентов, разработанных независимо друг от друга, код которых хранится в двух разных GitHub-репозиториях. Это — репозиторий base-ui ^[4] (вот ^[5] соответствующая Bit-коллекция) и репозиторий evangelist ^[6] (вот ^[7] Bit-коллекция этих компонентов).

Коллекция компонентов base-ui

Коллекция компонентов evangelist

Коллекция base-ui играет роль дизайн-системы. Компоненты в коллекции evangelist применяются на маркетинговых страницах проекта. В них используются некоторые компоненты из base-ui. Это сделано ради обеспечения единообразного внешнего вида различных микрофронтендов.

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

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

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

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

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

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

Формирование интерфейса производится на клиенте

Подобный паттерн реализован в следующих фреймворках:

• Piral ^[8]
• Open Components ^[9]
• qiankun ^[10]
• Luigi ^[11]
• Frint.js ^[12]

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

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

Формирование интерфейса производится на сервере

Вот фреймворки, в которых реализован такой (или похожий) паттерн:

• Mosaic ^[13]
• PuzzleJs ^[14]
• Podium ^[15]
• Micromono ^[16]

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

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

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

Организация совместного использования зависимостей с помощью карт импорта

Вот некоторые библиотеки, использование которых позволяет сократить объём шаблонного кода, который приходится писать при разработке микрофронтендов:

• Module Federation ^[17]
• Siteless ^[18]
• Single SPA ^[19]
• Postal.js ^[20]
• EventBus ^[21]

Чего можно ожидать от микрофронтендов в будущем?

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

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

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

Одна из причин этого связана с микросервисами и заключается в том, что микросервисы не рассматриваются в виде одного из инструментов, применимых в специфических сценариях. Их видят скорее как набор «лучших практик» и стандартов проектирования бэкендов. Это, очевидно, неправильно. В результате и микрофронтенды тоже не стоит рассматривать как универсальное решение.

Итоги

То, как много существует решений, направленных на разработку микрофронтендов, и то, как широко распространена эта технология, даёт нам чёткий сигнал: «Микрофронтенды готовы к тому, чтобы ими пользовались». Но перед тем, как применять микрофронтенды в некоем крупном реальном проекте, я порекомендовал бы ознакомиться с различными паттернами и решениями, направленными на их разработку.

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

^[22]

^[23]

Автор: ru_vds

Источник ^[24]