Начало работы с микрофронтендами

Фотография Mourizal Zativa на Unsplash

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

В большинстве случаев при современном состоянии разработки веб-приложения мы видим, что это многофункциональное и мощное приложение, которое называется Single Page App или SPA. Такие типы приложений создаются с использованием одного фронтенд-фреймворка или библиотеки, например Angular, React и т. д.

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

С другой стороны, у нас есть подход к использованию архитектур Micro Frontend. Проще говоря,

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

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

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

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

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

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

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

Вот некоторые из основных преимуществ, почему вы должны выбрать именно их:

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

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

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

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

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

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

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

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

   Но, как мы знаем, подход micro frontend — это как «разделяй и властвуй»; выбрав эту архитектуру для своего следующего веб-приложения, вы сможете облегчить тестирование и сопровождение ваших бизнес-требований.

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

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

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

Проблемы микрофронтендов

Вот пять проблем, о которых следует помнить:

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

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

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

   Разные команды могут обновлять каждое приложение и, следовательно, выпускать и изменять его независимо друг от друга. Но предположим, что в своем веб-приложении вместо использования встроенных навигационных утилит вы создаете свою собственную систему навигации, что добавляет сложности. Для этого вы должны передать состояние приложения между отдельными приложениями и проверить, кто отвечает за сохранение полного состояния приложения.

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

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

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

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

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

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

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

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

Сравнение решений для микрофронтендов

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

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

1) Single SPA: вкратце Single SPA — это:

JavaScript-маршрутизатор для микросервисов фронтенда.

Это фреймворк для объединения нескольких JavaScript-микрофронтендов во фронтенд-приложение, и в основном он заботится о кросс-фреймворковых компонентах. Это означает, что вы используете несколько фреймворков, таких как React, Angular, Ember и т.д., на одной странице без обновления страницы.

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

2) Федерация модулей: построена на принципе, что:

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

В целом, Module Federation заботится только о совместном использовании зависимостей и в значительной степени зависит от инструментария. Например, после загрузки компонента React ваше приложение не будет импортировать код React дважды после загрузки, а будет использовать уже загруженный источник и затем импортировать только код компонента.

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

3) Piral: Piral — это фреймворк для портальных приложений нового поколения.

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

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

Он поможет вам создать модульное фронтенд-приложение, расширяемое во время исполнения, и поставляется с разделенными модулями, называемыми «сваями». Модуль может быть использован для:

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

Оболочка приложения Piral называется экземпляром Piral, который:

• Создает общий дизайн приложения (например, верхний и нижний колонтитулы, навигацию и т.д.).
• Включает общие компоненты, которые могут использоваться сваями.
• Определяет, как загружаются свайпы и где свайпы могут интегрировать свои компоненты.

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

Создание вашего первого приложения с Piral

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

Команда разработчиков Piral создала несколько готовых к использованию оболочек приложений. Одной из них является оболочка «sample-piral». Для начала разработки микрофронтенда для этого приложения требуется только npm и Node.js. В командной строке новой директории выполните:

npm init pilet -- --source sample-piral --bundler esbuild --defaults

Примечание: В порядковых версиях npm (6) переадресующие тире (—) можно не ставить.

Теперь пилюля должна быть готова. Давайте посмотрим на код. Самый важный файл — src/index.tsx. Здесь все сходится воедино. Давайте изменим исходный код на следующий:

import * as React from 'react';
import { PiletApi } from 'sample-piral';

export function setup(app: PiletApi) {
  app.showNotification('Hello from Piral!', {
    autoClose: 2000,
  });
  app.registerMenu(() =>
    <a href="https://docs.piral.io" target="_blank">Documentation</a>
  );
  app.registerTile(() => <div>Welcome to Piral!</div>, {
    initialColumns: 2,
    initialRows: 1,
  });
}

чтобы отображать только ту страницу, которая стала видимой по ссылке:

import * as React from 'react';
import { Link } from 'react-router-dom';
import { PiletApi } from 'sample-piral';

const MyPage = React.lazy(() => import('./Page'));

export function setup(app: PiletApi) {
  app.registerMenu(() =>
    <Link to="/my-page">My Page</Link>
  );
  app.registerPage("/my-page", MyPage);
}

В коде мы — кроме самой функции setup — не используем ничего пользовательского. Использование Link и React.lazy знакомо любому разработчику React. Это основная философия, лежащая в основе Piral. Ворды должны просто использовать концепции базовых фреймворков. Поэтому не требуется мета-маршрутизатор, как в single-spa. Единственная новая концепция заключается в том, что компоненты теперь должны быть зарегистрированы, где / как они должны быть использованы.

Код для страницы находится в src/Page.tsx. Он гласит:

import * as React from 'react';
import { PageComponentProps } from 'sample-piral';

const Page: React.FC<PageComponentProps> = ({ piral: app }) => {
  return (
    <>
      <h1>My Page</h1>
      <p>This is some text.</p>
      <app.Extension name="important-info" />
      <p>Some more text.</p>
    </>
  );
};

export default Page;

Страница на самом деле довольно проста в своей логике. Но, присмотревшись, вы увидите, что мы также поместили туда один специальный элемент. Предоставленный piral prop ссылается на API, который позволил нам ранее регистрировать страницы и многое другое. Теперь мы можем использовать тот же API для создания слота расширения.

Слот расширения — это конструкция, которая очень похожа на то, что могут предложить веб-компоненты. Допустим, у нас есть следующий HTML-код:

<h1>My Page</h1>
<p>This is some text.</p>
<x-important-info></x-important-info>
<p>Some more text.</p>

Если загружен скрипт, который выполняет вызов customElements.define с элементом «x-important-info», то что-то будет показано. В противном случае место может просто остаться пустым.

К сожалению, у веб-компонентов есть несколько недостатков, которые делают их менее идеальными для таких мест размещения:

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

Тем не менее, для наглядной иллюстрации того, что такое слот расширения, веб-компоненты предоставляют полезную модель.

Давайте запустим микрофронтенд, выполнив следующие действия

npm start

который под капотом запустит pilet debug. Браузер покажет страницу, подобную этой:

В целях тестирования мы также можем заполнить место, отведенное под заполнитель. Для этого мы можем зарегистрировать расширение в src/index.tsx. Измените его следующим образом:

import * as React from 'react';
import { Link } from 'react-router-dom';
import { PiletApi } from 'sample-piral';

const MyPage = React.lazy(() => import('./Page'));

export function setup(app: PiletApi) {
  app.registerMenu(() =>
    <Link to="/my-page">My Page</Link>
  );
  app.registerPage("/my-page", MyPage);

  if (process.env.NODE_ENV === 'development') {
    app.registerExtension('important-info', () => (
        <p>
            <strong>WARNING</strong> Test extension
        </p>
    ));
  }
}

Браузер должен автоматически обновиться. Теперь страница выглядит следующим образом:

Отлично! Как же вы можете вывести такой микро-фронтенд в онлайн? Есть несколько способов, но самым простым может быть использование официального сервиса Piral Cloud feed. Этот сервис является бесплатным для целей личного развития. Вы можете просто войти в систему через существующую учетную запись Microsoft на сайте https://feed.piral.cloud.

Нажав на «Создать фид», вы можете ввести новое (уникальное) имя фида и некоторые данные.

Теперь нажмите кнопку «Создать» и, наконец, вы окажетесь на странице, где будут показаны текущие фиды. Сейчас у нас их нет.

Теперь мы можем либо создать API-ключ и опубликовать пилет из командной строки, либо просто загрузить пилет через веб-интерфейс. Давайте автоматизируем это прямо сейчас, нажав на символ («Manage API keys»), а затем на кнопку «Generate API Key».

Дайте ключу имя, а остальное оставьте как есть. Область видимости по умолчанию («pilets.write») будет достаточно. Затем нажмите на кнопку «Сгенерировать». Нажмите на сгенерированный ключ, чтобы скопировать его.

В командной строке запустите из каталога pilet:

npx pilet publish --fresh --api-key <copied-key> --url <feed-url>

где часть copied-key должна быть заменена на скопированный ключ. Часть feed-url должна быть заменена на URL вашего фида. В моем случае команда выглядела следующим образом:

npx pilet publish --fresh --api-key bd3e907b54c1b275cc... --url https://feed.piral.cloud/api/v1/pilet/vk-pilets

Портал должен автоматически обновиться и теперь отображать список пилетов:

Замечательно — вы только что опубликовали свой первый микрофронтенд. Но как вы можете его использовать? В конце концов, у нас нет никакой страницы в Интернете. Одна вещь, которую мы можем сделать здесь, это просто клонировать репозиторий Piral — где разработана оболочка приложения sample-piral. Однако это довольно громоздко и не очень хорошо. Другой вариант — просто создать новую оболочку приложения и указать ее на текущий фид.

В новом каталоге запустите:

npm init piral-instance -- --bundler esbuild --defaults

После установки откройте src/index.tsx в текстовом редакторе и измените

const feedUrl = 'https://feed.piral.cloud/api/v1/pilet/empty';

на

const feedUrl = 'https://feed.piral.cloud/api/v1/pilet/vk-pilets';

где конкретный URL — это тот, который вы использовали для публикации вашего pilet ранее. Теперь запустите npm start в командной строке.

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

В новом каталоге снова запустите команду npm init для создания pilet. Опять же, мы можем выбрать sample-piral в качестве оболочки приложения для опробования/отладки pilet. Измените src/index.tsx:

import * as React from 'react';
import { PiletApi } from 'sample-piral';

const MyExtension = React.lazy(() => import('./MyExtension'));

export function setup(app: PiletApi) {
  app.registerExtension("important-info", MyExtension);
}

Файл src/MyExtension.tsx выглядит следующим образом:

import * as React from "react";

function MyExtension() {
  const [count, setCount] = React.useState(0);
  const increment = React.useCallback(() => setCount((count) => count + 1), []);

  return (
    <div>
      <button onClick={increment}>Clicked {count} times</button>
    </div>
  );
}

export default MyExtension;

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

После публикации мы можем вернуться и посмотреть на агрегацию обоих микрофронтендов в одном представлении:

Даже не запуская собственную оболочку, мы можем отлаживать оба вместе. piral-cli поддерживает одновременный запуск нескольких микрофронтендов. Из первого запуска pilet:

npx pilet debug ../first-pilet ../second-pilet

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

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

Заключение

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

Далее мы кратко сравнили различные подходы к микрофронтендам. Наконец, мы рассмотрели, как создать свое первое приложение на Piral с помощью Piral Feed Service.