Микро-frontends са вълнуващ и футуристичен подход към модерното уеб развитие. Ако работите върху сложно/голямо приложение и не използвате микро-frontends, вероятно скоро ще имате нужда от тази технология.

Здравейте приятели! В тази публикация ще научим как да работим със сложни и големи приложения, използвайки микро-интерфейси. Както подсказва името, целта е да се изолираприложението в по-малки приложения и да се интегрират всички в окончателното изискване. Звучи яко ? То е. Нека разгледаме частта как*.

Micro Frontends са малки, самостоятелни уеб приложения, които споделят обща предна кодова база. Те комуникират помежду си чрез споделен API. Предният край на приложението е разложен на отделни, слабо свързани „микро приложения“, които могат да бъдат изграждани, тествани и внедрявани независимо.

*добре е да имате основни познания за внедряването на webpack.

Нуждата и ползите

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

Мащабируемост
Фактът, че едно приложение е мащабируемо, ни позволява, от бизнес гледна точка, да можем да продължим да растем според нуждите на проекта, без да губим качествата, които добавят стойност към него, добавяйки новите.

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

Независимост и автономност
Всеки микро-frontend може да се разработва паралелно, без да зависи от другите. Различните части на хост приложението могат да имат различни версии и да бъдат тествани и внедрявани индивидуално.

💡 Използването на верига от инструменти с отворен код като Bit за внедряване на микро интерфейси гарантира, че ще се насладите на тези предимства и също така рационализира цялата процедура. Чрез възприемане на композируем, на първо място модулен дизайн за вашите компоненти и независимо съхраняване, тестване и документиране на атомарни единици от потребителския интерфейс вместо цели приложения наведнъж, вашето приложение се мащабира по-добре и е безкрайно по-лесно за поддръжка. Това ръководство ще ви покаже как.

Научете повече тук:



Архитектурата

Интеграциите

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

Нека вземем примера на прекалено опростено уеб приложение за електронна търговия. Ще наричаме базовото (крайно) приложение като контейнер. Списъкът с продукти е внедрен в приложението за продукти, а показването на количката е внедрено в приложението за количка. Следователно имаме три различни кодови бази, с които да работим.

По отношение на интегрирането на всяко микроприложение в хост приложението, бихме могли да използваме следните технически подходи:

  • Интеграция от страна на клиента: Браузърът обработва интеграцията.
  • Интеграция от страна на сървъра: Сървърът управлява интеграцията.
  • Интеграция по време на компилация: Интеграцията се извършва по време на компилация.

Инструменти като Webpack Federation Module могат да ни помогнат да работим с нашите микро-frontends.

Webpack е кодов пакет за javascript. Можем да опростим използването му, както следва:

До края на 2020 г. Зак Джаксън пусна своя шедьовър „Module Federation“ като плъгин в Webpack 5. Приставката Module Federation промени света на Micro-frontends на напълно ново ниво.

Прилагането

Ние ще внедрим интеграции от страна на клиента или по време на изпълнение в нашата примерна реализация за електронна търговия. Тази интеграция има следните предимства:
1. ProductList може да бъде внедрен независимо по всяко време.
2. Различни версии на ProductList могат да бъдат внедрени и контейнерът може да реши коя да използва.

Сложната или по-отнемаща много време част е инструментите и настройката.

Ние ще използваме силата на модулната федерация, предоставена от webpack 5. Изпълнението може да бъде обобщено в следващите стъпки.

  1. Определете едно уеб приложение като хост (контейнер), а други като отдалечено (продукти и количка).
  2. В Remote преместете приложимите функции, за да ги направите достъпни за друго уеб приложение. И тези файлове могат да бъдат изложени с помощта на Module Federation.
  3. В Host импортирайте необходимите функции от Remote

Кодовите бази за нашите три приложения могат да се намират в различни хранилища или в едно и също хранилище под различни папки. За опростяване, нека използваме последната опция.
Освен това всяко приложение може да има различна технология. В нашия случай ще използваме React.js за всички приложения.

Нека използваме create-react-appи да създадем три различни приложения за реакция, а именно контейнер, количка и продукти. Зависимостите под package.json от тях трябва да изглеждат по следния начин:

Faker се използва за генериране на фалшиви API данни за примерното приложение.

Ще добавим webpack.config.js под всяка основна папка и нашата окончателна структура на папките трябва да изглежда по следния начин:

конфигурация на webpack за първото изолирано приложение — продуктите:

const HtmlWebpackPlugin = require("html-webpack-plugin");
const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");

module.exports = {
  mode: "development",
  devServer: {
    port: 8081,
  },
  plugins: [
    new ModuleFederationPlugin({
      name: "products",
      filename: "remoteEntry.js",
      exposes: {
        "./ProductsIndex": "./src/bootstrap",
      },
      shared: ["faker"],
    }),
    new HtmlWebpackPlugin({
      template: "./public/index.html",
    }),
  ],
};

конфигурация на webpack за второто изолирано приложение - количката:

const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  mode: 'development',
  devServer: {
    port: 8082,
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'cart',
      filename: 'remoteEntry.js',
      exposes: {
        './CartShow': './src/bootstrap',
      },
      shared: ['faker'],
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
};

конфигурация на webpack за основното приложение — контейнера:

const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  mode: 'development',
  devServer: {
    port: 8080,
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        products: 'products@http://localhost:8081/remoteEntry.js',
        cart: 'cart@http://localhost:8082/remoteEntry.js',
      },
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
};

И така, какво се случва тук?

Нашите изолирани приложения, продукти и количка работят съответно на портове 8081 и 8081. Контейнерът е на порт 8080.

Всяко от нашите изолирани приложения, продукти и количка излага основната кодова база на приложението, наречена съответно ProductsIndex и CartShow. Това са конкретните имена, които ще използваме, за да монтираме тези приложения под контейнера.

Сега контейнерът може да има достъп до изолираните приложения чрез свойството име на файл на ModuleFederationPlugin под всяко приложение, използвайки отдалеченото свойство като-

remotes: {
    products: 'products@http://localhost:8081/remoteEntry.js',
    cart: 'cart@http://localhost:8082/remoteEntry.js',
  }

Вътре в index.js на контейнер можем да монтираме изолираните приложения като:

import { mount as productsMount } from 'products/ProductsIndex';
import { mount as cartMount } from 'cart/CartShow';

console.log('Container!');

productsMount(document.querySelector('#products-app'));
cartMount(document.querySelector('#cart-app'));

Където products-app и cart-app са Id селектори на HTML елементи, където ще бъдат монтирани тези приложения.

Това е всичко за внедрявания!

Миграцията: съществуваща кодова база към микро-интерфейс

Това е най-разумната част: намирането на бюджет за мигриране на модул, който ще бъде същият, но различен по някакъв начин, не е лесно. Можем да следваме четири различни стратегии, за да улесним процеса:

  1. Трябва да се уверим, че използваме най-новия React с версия, по-голяма от 17. React v17 и по-висока ще бъдат оборудвани с Webpack версия 5 или по-нова, която има функциите на Micro frontends.
  2. Изберете типа интеграция на Micro frontend, който отговаря на вашето приложение.
  3. Модифицирайте файла webpack.config (основно за интеграция по време на изпълнение) за функционалността за излагане и отдалечен достъп.
  4. Опитайте се да изградите глобални услуги (като удостоверяване, известяване и т.н.) в приложението, специфични за функционалността или частта, която искате да изградите като микро интерфейс.

Дори ако не използвате MFE днес във вашия проект, добра идея е да изпробвате POC или личен проект около тази концепция.

Благодаря за четенето!

Изградете Micro frontends с компоненти за многократна употреба

Инструментът с отворен код на Bitпомага на 250 000+ разработчици да създават приложения с компоненти.

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

Научете повече

Разделете приложенията на компоненти, за да улесните разработката на приложения и се насладете на най-доброто изживяване за работните процеси, които искате:

Микро-фронтенди

Система за проектиране

Споделяне на код и повторно използване

Монорепо

Научете повече: