Микрофронтенды — одна из самых противоречивых тем в мире веб-разработки.
Стоит ли их делать? Должен ли фронтенд быть разделен на части? Стоит ли использовать эту технологию прямо сейчас? Может быть, это очередная модная ерунда, от существования которой выигрывают только консультанты, зарабатывающие на этом деньги? 
Хотя микрофронтенды окружены много По слухам, нельзя отрицать, что эта технология с каждым днем становится все популярнее.
Автор статьи, перевод которой мы сегодня публикуем, предлагает поговорить о том, кто использует микрофронтенды, почему применяется эта технология и что может ускорить и упростить работу того, кто решит создать микрофронтенд-приложение.
Что такое микрофронтенды?
В рамках технологии микрофронтенда была предпринята попытка перенести в мир клиентской разработки полезные возможности, которые можно получить, разбивая большие бэкэнд-системы на микросервисы.Основная проблема здесь в том, что части, составляющие микрофронтенды, всегда используются или воспринимаются как единое целое.
Хотя бэкэнд-системы никогда не используются как монолитный объект, фронтенд — это система, которая напрямую отвечает за то, что называется «пользовательский опыт» (UX).
Существует множество подходов к решению проблемы разделения фронтенда на части.
Самый простой — заменить модель передачи данных, используемую в существующих API, на вывод готового HTML-кода.
Переход от одного сервиса (его визуального представления, внешнего вида) к другому осуществляется нажатием на гиперссылку.
Обратной стороной этого вполне работоспособного подхода является то, что он явно не обеспечит желаемого UX для большинства сценариев работы с веб-проектами.
«Эволюция распределенных веб-приложений: монолит, разделение фронтенда и бэкенда, микросервисы, микрофронтенды».
Очевидно, что использование микрофронтендов подразумевает необходимость использования достаточно сложных методов объединения небольших фрагментов интерфейса, разрабатываемых независимо друг от друга, в единую систему.
Микрофронтенды представляют собой следующий этап в разработке распределенных веб-приложений.
Говоря о частях микроинтерфейса, интересно спросить, как они связаны с компонентами и модулями.
Как оказывается, все эти концепции направлены на то, чтобы попытаться реализовать многократное использование определенных элементарных сущностей, на попытку разделить обязанности между такими сущностями.
Единственная разница между частями, компонентами и модулями микроинтерфейса — это уровень абстракции, который они представляют.
- Компоненты — это строительные блоки библиотек пользовательского интерфейса.
- Модули — это то, что составляет базу кода.
- Пакеты — это элементы систем разрешения зависимостей.
- Части микрофронтенда — это сущности, из которых собираются готовые приложения.
Почему используются микроинтерфейсы?
Есть много причин, по которым используются микроинтерфейсы.Часто основная причина их использования носит технический характер.
Однако в идеале причины использования микрофронтендов должны лежать в плоскости интересов бизнеса или в области улучшения UX. Микрофронтенд-решения, по сути, должны обладать следующими свойствами:
- Отдельные фрагменты интерфейса могут быть разработаны, протестированы и развернуты независимо.
- Части интерфейса поддерживают добавление, удаление и замену без необходимости пересборки проекта.
- Различные интерфейсные блоки могут быть созданы с использованием разных технологий.
Одним из преимуществ этого подхода является то, что он позволяет более четко разделить ответственность между командами разработчиков.
Это, помимо прочего, способствует созданию более компактных full-stack команд. 
Компактные команды разработчиков полного стека
Использование микрофронтендов в проекте может быть особенно оправдано, если окажется, что для этого проекта выполняется одно или несколько из следующих условий:
- Несколько команд участвуют в создании интерфейса.
- Отдельные части внешнего интерфейса следует активировать, деактивировать или выпускать в зависимости от конкретных пользователей или определенных групп пользователей.
- Внешние разработчики должны иметь возможность расширять интерфейс проекта.
- Спектр возможностей интерфейса постоянно расширяется, ежедневно или еженедельно.
Однако эти изменения не затрагивают другие части системы.
- Скорость разработки должна быть постоянной и не должна зависеть от скорости роста приложения.
- Разные команды разработчиков должны иметь возможность использовать свои собственные инструменты.
Кто использует микрофронтенды?
Все больше компаний активно используют микрофронтенды.Вот текущий список некоторых из этих компаний:
- ДАЗН
- Эльзевир
- энтандо
- Фиверр
- Привет Свежий
- ИКЕА
- Bit.dev
- Майкрософт
- Открытый стол
- OpenMRS
- Отто
- САП
- Сикст
- Скайсканер
- Смапиот
- Спотифай
- Старбакс
- Талия
- Заландо
- ЦЕЙС
Компании, использующие микроинтерфейсы
Список компаний, использующих микрофронтенды, растет с каждым днем.
Здесь вы можете найти широкий спектр организаций: от консалтинговых фирм, таких как ThoughtWorks и HLC, до поставщиков SaaS, таких как SalesPad или Apptio. Одним из примеров является немецкая компания Hoffmann Group, которую, пользуясь терминологией Германа Симона, можно назвать «скрытым чемпионом».
Пример Hoffmann Group прекрасно иллюстрирует, что использование микрофронтендов не требует больших команд и нет необходимости разрабатывать микрофронтенды собственными силами.
Эта компания выбрала микроинтерфейсы прежде всего потому, что ей приходилось взаимодействовать с несколькими поставщиками услуг.
Пример построения микрофронтенда на основе компонентов
Платформа Bit.dev , а также его маркетинговый веб-сайт построены с использованием компонентов React, которые управляются с помощью одной и той же платформы.Взгляни на этот страница.
Если вы наведете на него указатель мыши, указывая на разные части страницы, вы увидите всплывающие подсказки, сообщающие, к каким «исходным коллекциям» принадлежат эти компоненты.
Для того, чтобы изучить компонент, необходимо нажать на его название (оно отображается над компонентом).
Вы даже можете интегрировать такой компонент в свой проект. 
Информация о компоненте отображается на странице
Эта страница создана из компонентов, разработанных независимо друг от друга, код которых хранится в двух разных репозиториях GitHub. Это репозиторий базовый интерфейс ( Здесь соответствующая коллекция битов) и репозиторий евангелист ( Здесь Битовая коллекция этих компонентов).
Коллекция компонентов base-ui 
Коллекция компонентов Евангелиста
Коллекция base-ui играет роль дизайн-системы.
Компоненты коллекции евангелистов используются на маркетинговых страницах проекта.
Они используют некоторые компоненты из base-ui. Это сделано для обеспечения единообразного внешнего вида различных микроинтерфейсов.
Здесь платформа Bit используется как в качестве платформы для поддержки автономных возможностей, так и в качестве механизма для поддержки согласованного интерфейса между различными микроинтерфейсами.
Как создавать микро-интерфейсы?
Название этого раздела поднимает интересный вопрос.Но, к сожалению, однозначно ответить на него невозможно.
Как и в случае с микросервисами, не существует универсального подхода, который бы подходил всем, кому нужны микроинтерфейсы.
В этой области нет развитого промышленного стандарта.
В отличие от микросервисов, микрофронтенды отличаются друг от друга не только деталями реализации, но и базовыми технологиями, используемыми для их создания.
В результате, говоря о микрофронтендах, нужно учитывать помимо технической стороны дела, какова основная область их применения.
Например, их можно отличить по поддержке серверного рендеринга по фреймворку, на котором они основаны.
Между ними можно обнаружить множество других фундаментальных различий.
▍Клиентские фреймворки
Клиентские микрофронтенды — это область, где встречаются самые разные фреймворки.Некоторые из них поддерживают серверный рендеринг.
Интерфейс создается на клиенте
Похожий шаблон реализован в следующих фреймворках:
▍Серверные фреймворки
Если говорить о реализации микрофронтендов, в основе которых лежат серверные фреймворки, то здесь тоже есть на что посмотреть.Некоторые из них основаны на экспрессе, другие существуют в виде сервисов, которые необходимо развертывать с использованием собственной инфраструктуры.
Интерфейс создается на сервере
Вот фреймворки, реализующие этот (или аналогичный) шаблон:
▍Вспомогательные библиотеки
Некоторые вспомогательные библиотеки также могут помочь нам в реализации микрофронтендов.Они либо направлены на создание инфраструктуры совместного использования зависимостей и маршрутизации событий, либо просто обеспечивают взаимосвязь различных частей микроинтерфейсов и жизненных циклов этих частей.
Одним из примеров является поддержка общих зависимостей с помощью различных механизмов, таких как карты импорта или инструменты связывания.
Совместное использование зависимостей с помощью карт импорта
Вот несколько библиотек, использование которых позволяет сократить количество шаблонного кода, который приходится писать при разработке микрофронтенда:
Чего мы можем ожидать от микроинтерфейсов в будущем?
Хотя наличие вспомогательных библиотек, таких как Module Federation, может создать впечатление конвергенции различных технологий разработки микроинтерфейсов, большинство разработчиков предпочитают использовать собственные решения.Хорошо здесь то, что существует множество фреймворков, упрощающих разработку микрофронтендов, что не приводит к чрезмерной зависимости разработчиков от производителей тех или иных решений.
В любом случае, чего не хватает в рассматриваемой нами области, так это общепринятого стандарта, который хотя бы с технической точки зрения упростил бы взаимозаменяемость разных решений.
Чего не хватает микрофронтендам в наши дни, так это более широкого их внедрения сообществом разработчиков.
Хотя паттерн микрофронтенд набирает популярность, многие разработчики до сих пор сомневаются в целесообразности его использования.
Одна из причин этого связана с микросервисами и заключается в том, что микросервисы не рассматриваются как один из инструментов, применимых в конкретных сценариях.
Их рассматривают скорее как набор «лучших практик» и стандартов серверной разработки.
Это очевидно неправильно.
В результате микрофронтенды также не следует рассматривать как универсальное решение.
Полученные результаты
Количество существующих микрофронтенд-решений и степень распространения этой технологии ясно дают понять: «Микрофронтенды готовы к использованию».Но прежде чем использовать микрофронтенды в большом реальном проекте, я бы рекомендовал ознакомиться с различными паттернами и решениями, направленными на их разработку.
Как вы относитесь к микрофронтендам? 
Теги: #разработка сайтов #разработка #микрофронтенд
-
Тарифные Планы Мобильной Сотовой Связи
19 Oct, 24 -
Эмпедокл
19 Oct, 24 -
Новая Концепция Интерфейса Яндекс.почты
19 Oct, 24 -
Блог Компании Эр-Телеком
19 Oct, 24
