Ако вече знаете какво е микро интерфейс, преминете към раздела за внедряване.

Представете си, че се намирате в контекст като този: работите по фронтенд проект, който има много бизнес единици със собствени правила и логика. Един екип е назначен да се грижи за една от тези бизнес единици. Проблемът е, че всички тези бизнес единици се съдържат в един и същ фронтенд проект (монолит), поставяйки в една и съща кодова база различни бизнес правила и логика. Този проект се разраства и в резултат на това вие и, разбира се, другите екипи се сблъсквате с някои проблеми, като:

  1. Внедряването отнема толкова време
  2. Огромно време за извършване на тестове
  3. Свързани кодови бази, без ясно разделяне на контекстите
  4. Екипи, зависими един от друг, за извършване на прости работи

Какво да направите в случай като този?

Това е вече известен проблем при разработката на бекенда. Microservices беше подходът, използван за решаване на този проблем от страна на бекенда. И така, какъв е подходът, използван от предната страна? Микро интерфейси!

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

Предимства и недостатъци

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

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

Освен предишните точки, има някои случаи, когато микро интерфейсът не е идеалният вариант, като например внедряването му в малки проекти.

И така, отговорът на въпроса „трябва ли да сменя на микро интерфейс?“ всъщност е отговорът за всичко в софтуерното инженерство: зависи.

Ако искате да навлезете задълбочено в концепциите за микро интерфейс, проверете тази статия.

Внедряване

Това обяснение се основава на това репо

Концептуално това приложение симулира куриер, който по своята същност съдържа някои модули, свързани с транспорта. Тук исках просто да създам само две от тях, управление на пратки и проследяване на пратки.

Технически казано, той е съставен основно от четири части (които са папки в предишното репо), които са:

  1. гълъб (червено) — Тази част от приложението използва концепцията за хостмикро интерфейс, който е „контейнерът“ на всички дистанционни приложения, хост приложение „деца“.
  2. Приложение за проследяване (синьо) — едно от отдалечените („дете“) приложения, отговорно за показване на данни за проследяване, свързани с конкретна пратка
  3. Приложение за пратки (зелено) — едно от отдалечените („дете“) приложения, отговорно за показване на всички потребителски пратки
  4. Пакет с персонализирани елементи на NPM — проект, който се състои от пакет NPM, който има за цел да намали повторното внедряване на код около компоненти без състояние, като бутони, текстове за въвеждане, таблици и т.н. Всички компоненти на този пакет могат да се използват повторно в трите предишни проекта

Как е свързано всичко?

Първите три проекта, цитирани по-рано, са свързани чрез vite-plugin-federation, библиотека, която позволява на разработчиците да използват концепцията module federation с инструмента Vite bundle. Обобщавайки, обединяването на модули е подход, който се състои в изграждане на приложения по начин, позволяващ повторното им използване в други приложения.

От отдалечената страна това, което трябва да направите, за да обслужвате този проект на страната на хоста, е да инсталирате 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, за да не разработвам компоненти от нулата, използвах повторно четири компонента от тези пакети, само за да докажа концепцията. Повторно използваните компоненти бяха: бутон, вход, таблица и времева линия. Сега просто трябва да инсталирам пакета в проекта, в който искам да използвам компонента, и да го използвам нормално. Проектът ще има последователен потребителски интерфейс, тъй като стилът ще бъде същият и няма да са необходими повторни реализации за същия компонент.

Ако искате да проверите как е внедрен пакетът, погледнете проекта в репо.

Micro frontend е невероятна архитектура за използване в сложни проекти и екипи. Но го използвайте разумно и имайте предвид, че всички архитектури и инструменти имат недостатъци. Обмислете ги, направете своята оценка и животът ви ще бъде щастлив.

Надявам се да ви е харесало! Ако имате въпроси, просто ми кажете!

Ще се видим

Внедряване: https://github.com/vitorlofonseca/microfrontend-vue-and-vite

Препратки: https://martinfowler.com/articles/micro-frontends.html