Если вы уже знаете, что такое микроинтерфейс, перейдите к разделу реализации.

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

  1. Развертывание занимает так много времени
  2. Огромное количество времени для выполнения тестов
  3. Связанные кодовые базы без четкого разделения контекстов
  4. Команды зависят друг от друга для выполнения простых работ

Что делать в таком случае?

Это уже известная проблема в backend-разработке. Микросервисы были подходом, используемым для решения этой проблемы на стороне сервера. Итак, какой подход используется на стороне переднего плана? Микроинтерфейсы!

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

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

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

  1. Размер пакета проекта из-за дублирования пакетов между микроинтерфейсами. Этого можно избежать в зависимости от подхода, который вы используете для создания микроинтерфейсов. В нашем случае реализации, используя vite-plugin-federation, мы можем настроить пакеты, которые будем использовать, из хост-приложения, а не устанавливать его дважды.
  2. Большая независимость команд может привести к некоторой анархии. Это не очень плохой момент, если компания хорошо с этим справляется. В противном случае этого можно избежать, определив некоторые групповые политики, такие как команда модераторов, оценивающая запросы на вытягивание и другие.

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

Итак, ответ на вопрос «стоит ли переходить на микрофронтенд?» в основном ответ на все в программной инженерии: это зависит.

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

Выполнение

Это объяснение основано на этом репозитории

Концептуально это приложение имитирует курьера, который по своей природе содержит некоторые модули, связанные с транспортировкой. Здесь я хотел просто создать только два из них: управление отгрузкой и отслеживание отгрузки.

С технической точки зрения, он состоит в основном из четырех частей (это папки в предыдущем репозитории), а именно:

  1. голубь (красный). В этой части приложения используется концепция микроинтерфейса host, который является «контейнером» всех удаленных приложения, хост-приложение «дочерние».
  2. Приложение-трекер (синее) — одно из удаленных («дочерних») приложений, отвечающее за отображение данных отслеживания, относящихся к конкретному отправлению.
  3. Приложение «Отправки» (зеленое) — одно из удаленных («дочерних») приложений, отвечающее за отображение всех отправлений пользователя.
  4. Пакет пользовательских элементов NPM — проект, состоящий из пакета NPM, целью которого является сокращение повторной реализации кода вокруг компонентов без состояния, таких как кнопки, вводимые тексты, таблицы и т. д. Все компоненты этого пакета можно повторно использовать в трех предыдущих проектах.

Как все связано?

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

На удаленной стороне, чтобы обслуживать этот проект на стороне хоста, вам нужно установить vite-plugin-federation и использовать его в vite.config.ts следующим образом:

import { defineConfig } from "vite";
import federation from "@originjs/vite-plugin-federation";

export default defineConfig({
  ...
  preview: {
    port: 5005, //port you want to serve this remote
  },
  plugins: [
    ...
    federation({
      name: "pigeon-tracker", //name of remote you want to use on host side
      filename: "pigeonTracker.js", //filename after the build
      exposes: {
        "./App": "./src/App.vue",  //target component you want to serve as remote side. In our case is the entire application
      },
      shared: ["vue"],  //we don't want to build our remote with a library the host side already have. So here we sinalize "hey, use this host side package"
    }),
  ],
});

После настройки удаленной стороны мы хотим настроить хост-сторону. Это можно сделать следующим образом:

import { defineConfig } from "vite";
import federation from "@originjs/vite-plugin-federation";

export default defineConfig({
  ...
  plugins: [
    ...
    federation({
      name: "pigeon-app",  //app name
      remotes: {
        pigeon_tracker: "http://localhost:5005/assets/pigeonTracker.js",  //remote path containing the port configured on remote side, the build path, and the filename also configured on the remote side
      }
    }),
  ],
});

Теперь, когда обе стороны настроены, если вы используете Typescript в основном проекте, вы должны сообщить ему, что собираетесь использовать пользовательский модуль. Это можно сделать, создав файл d.ts, в моем случае remotes.d.ts.

declare module "pigeon_tracker/App"; //the name of the remote configured on the host side / the name of the module defined on the remote application

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

import { createRouter, createWebHistory } from "vue-router";
import HomeView from "../views/HomeView.vue";

const router = createRouter({
  history: createWebHistory(import.meta.env.BASE_URL),
  routes: [
    {
      path: "/",
      name: "home",
      component: HomeView,
    },
    {
      path: "/tracker",
      name: "tracker",
      component: () => import("pigeon_tracker/App"), //the name defined on host's vite.config.ts, referring to remote name/remote name
    },
  ],
});

export default router;

Таким образом, когда пользователь обращается к http://localhost:hostPort/tracker, он/она получит доступ к независимому приложению через наш хост. Это полностью прозрачно для пользователя и удивительно гибко для разработчиков.

Если у вас есть сомнения по поводу того, как это реализовать, ознакомьтесь с этой замечательной документацией

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

Используя element-plus и ag-grid, чтобы не разрабатывать компоненты с нуля, я повторно использовал четыре компонента из этих пакетов просто для проверки концепции. Были повторно использованы следующие компоненты: кнопка, ввод, таблица и временная шкала. Теперь мне просто нужно установить пакет в проекте, в котором я хочу использовать компонент, и использовать его в обычном режиме. Проект будет иметь согласованный пользовательский интерфейс, поскольку стиль будет таким же, и повторная реализация для одного и того же компонента не потребуется.

Если вы хотите проверить, как был реализован пакет, загляните в проект в репозитории.

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

Надеюсь, вам понравилось! Если у вас есть какие-либо вопросы, просто скажите мне!

Увидимся

Реализация: https://github.com/vitorlofonseca/microfrontend-vue-and-vite

Ссылки: https://martinfowler.com/articles/micro-frontends.html