company_banner

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

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



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

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


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

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

В то время как бэкенд-системы никогда не используются как некая монолитная сущность, фронтенд — это система, которая напрямую ответственна за то, что называют «пользовательским опытом» (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, а также её маркетинговый сайт, построены с использованием React-компонентов, управление которыми организовано с помощью этой же платформы.

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


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

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


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


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

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

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

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


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

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

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


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


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

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


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


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


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

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


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


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

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


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

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


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


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

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

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

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

Итоги


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

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



RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Комментарии 17

    +16
    Скоро при заходе на сайт в браузере будут развёртываться несколько docker-образов :)
      +2
      в которых подняты приложения на electron
      +3

      Портлеты восстали из мертвых

        +8

        Каким образом эта хрень каждый раз попадает в лучшее за сутки?

          0
          И веб превратиться в базар изобретателей велосипедов…
            0
            превратиться

            В смысле превратится? (я не про мягкий знак). Веб таким родился, есть и будет есть!
            +1
            Пару лет назад делал приложение типа CRM-ки. Визуально была боковушка-сайдбар с кучей менюшек, и центральная контентная часть.
            Бекенд на symfony. Сверстал базовый шаблон с сайдбаром в серверном шаблонизаторе. Т.е. меню генерировалось на сервере. Каждый пункт меню — это ссылка, которая вела на отдельный серверный роут.
            При этом контентная часть была пустым дивом, в который уже грузилось мини-SPA приложение (react) в соответствии с текущим серверным роутом (пунктом меню).
            Т. е. на каждый серверный роут был отдельный twig-овский шаблон (унаследованный от базового) со своим отдельным подключёнными js- и css- бандлами, актуальными для данного пункта меню (роута).
            При достаточно функционально огромном приложении — получился довольно лёгковесный фронт, максимум 1,1мб на роут (там где графики всякие).
            Заголовок спойлера
            Можно было ещё вынести общие части (react и др.) в отдельный чанк и подключить его в базовом шаблоне. Чтобы браузер закешировал общий бандл и при переходе между пунктами меню выкачивал только нужное.


            Можно ли назвать такой подход «микрофронтендами»? хотя такого выражения тогда ещё вроде не было..))
              0
              При этом контентная часть была пустым дивом, в который уже грузилось мини-SPA приложение (react) в соответствии с текущим серверным роутом (пунктом меню).


              Круто. Я так понимаю, без iframe все это сделано? А можно при этом как-то осуществить взаимодействие ядро <-> миниприложение1 <-> миниприложение2? И нельзя ли пример кода глянуть, хотя бы схематично, как в div грузится SPA приложение?
                0

                А что сложного-то?


                export function InitModule(rootDiv) {
                    ReactDOM.render(<App/>, rootDiv);
                
                    return () => ReactDOM.unmountComponentAtNode(rootDiv);
                }

                Тут самое сложное — придумать как загрузить React и ReactDOM один раз, а не копировать в бандл для каждой страницы.


                А можно при этом как-то осуществить взаимодействие ядро <-> миниприложение1 <-> миниприложение2?

                Да без проблем, просто ядро и всю связь с ним придётся писать как вот тут: https://habr.com/ru/post/491684/


                Самое сложное в этой схеме (как и вообще в микрофронтедах) — придумать что именно должно находиться в ядре.

                  0
                  А что сложного-то?


                  Ну, я бэкенд разрабатываю, так что это для меня «не свои сани». А можно загрузить в div динамически? Т.е. у нас есть SPA, посылаем запрос на сервер, сервер возвращает набор неких URL — допустим, три штуки — содержимое этих URL грузим в три div, которые внутри нашего SPA. Можно это каким-то образом осуществить?

                  У нас сейчас для этого используется набор iframe, все работает почти так, как надо, но есть ряд неприятных моментов.
                    +1

                    Ну да, разумеется. Грузим бандл (через современный import, древний require.js или каким-нибудь велосипедом), достаём из него функцию InitModule и вызываем её.

                  +1
                  Я так понимаю, без iframe все это сделано?

                  Да

                  А можно при этом как-то осуществить взаимодействие ядро <-> миниприложение1 <-> миниприложение2?

                  В моём случае «ядро» (наверное, лучше называть обвязка) — это был только сайдбар с щепоткой нативного js, который отвечал за скрытие/раскрытие пунктов меню, и за кнопку-гамбургер на мобилках.
                  Тут главное чтоб функционал этих мини-spa которые живут на разных серверных роутах сильно не пересекался. Максимум редирект с одного spa в другое.
                  Но впринципе, я когда это всё делал, то подозревал что рано или поздно может понадобится взаимодействие между spa в бандле и внешней обвязкой. Условно при каком-то событии внутри spa раскрыть и подсветить какой-то пункт меню в сайдбаре. Я тогда закладывал, что буду делать это через кастомные события. Типа spa диспатчит какое-то кастомное событие, а сайдбар слушал бы и реагировал. Или наоборот, в сайдбаре допустим какой-то чекбокс включается (диспатчим своё событие), а в spa реагируем на него. Вобщем по модели «издатель-подписчик». Но до такого явно не доходило, т.к. у аналитиков и дизайнеров я был главный и их полёт фантазий мог приструнить..)

                  И нельзя ли пример кода глянуть, хотя бы схематично, как в div грузится SPA приложение?

                  Как-то так было.

                  Серверный шаблон:
                  {% extends 'base-layout.html.twig' %}
                  
                  {% block title %}
                      Traffic controller
                  {% endblock %}
                  
                  {% block stylesheets %}
                    {{ parent() }}
                    <link rel="stylesheet" href="{{ asset('css/traffic-controller/index.min.css') }}">
                  {% endblock %}
                  
                  
                  {% block content %}
                    <div class="app__content" id="root">
                      <span>загрузка ...</span>
                    </div>
                  {% endblock %}
                  
                  
                  {% block javascripts %} 
                    {{ parent() }}
                    <script>
                        window.__INITIAL_STATE__ = {
                            // какие-то уже готовые начальные поля для данного spa 
                            // полученные при серверном(!) рендеренге этого шаблона
                            user: {{ user }}
                        };
                    </script>
                    <script src="{{ asset('js/traffic-controller/index.min.js') }}"></script>
                  {% endblock %}
                  


                  Соответствующий индексный js:
                  import React from 'react';
                  import ReactDOM from 'react-dom';
                  import App from 'js/traffic-controller/parts/App.jsx';
                  
                  const rootNode = document.getElementById('root');
                  ReactDOM.render(<App />, rootNode); 
                  
                0

                У нас в компании микроофронтенд — это каждая страница, которая SPA, по факту большой репорт с кучей инфы. Делается, для того, что бы можно было независимо деплоить в связке с микросервисами.

                  +4
                  Кто использует микрофронтенды?
                  IKEA
                  Microsoft
                  SAP
                  Spotify

                  Ну то есть используют — огромные компании, с кучей народа, которым проще распилить ещё и фронтенд на микросервисы, чем договориться между собой что, как и когда запускать и тестировать, но при этом решение подается как нечно новое, универсальное, и на что надо посмотреть. И хотя в подавляющем большинстве контор этот подход нафиг ненужен, теперь на собеседованиях будут спрашивать ещё и микрофронтенды. Класс.
                    0
                    Именно. Главное уметь донести мысль, что всему своё место
                    0
                    Сталкивался с Open Components. Если сравнивать с (монолитом) на React, то разработка на этих компонентах — где каждый грузится асинхронно и имеет свое собственное (скрытое) состояние — на порядок сложнее связки React/Redux.
                      0

                      Значит, вы их использовали не по назначению. Зачем вам вообще знать синхронно или асинхронно компонент загрузился?

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

                    Самое читаемое