Мікрофронтенди на етапі побудови: Чому інверсія контролю має значення

pic

Мікрофронтенди (Micro Frontends, MFEs) стали домінуючим підходом до масштабування фронтенд-розробки, дозволяючи командам працювати незалежно над різними частинами додатка, зберігаючи при цьому єдиний користувацький досвід.

Хоча компоновка в час виконання (найчастіше реалізується за допомогою Module Federation) є широко обговорюваною темою, мікрофронтенди, що інтегруються на етапі побудови, пропонують переконливу альтернативу — підхід, який спрощує керування залежностями, покращує продуктивність і підвищує надійність.

Однак успішна інтеграція мікрофронтендів у хост-додаток (або "оболонку додатка", app shell) на етапі побудови вимагає ретельного архітектурного вибору. Патерн інверсії контролю (IoC, Inversion of Control) відіграє вирішальну роль у проектуванні масштабованої та підтримуваної архітектури мікрофронтендів. У цьому пості ми розглянемо, як IoC впливає на мікрофронтенди на етапі побудови і чому він є важливим для ефективної інтеграції.

Мабуть, найпопулярніший інструмент для інтеграції мікрофронтендів на етапі побудови — це Bit, який ми будемо використовувати як демонстраційний інструмент.

pic

pic

Перегляньте компоненти цього демо на платформі Bit.

Що таке мікрофронтенди на етапі побудови?

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

  • Остаточний бандл додатка містить усі необхідні мікрофронтенди. Не потрібно жодної оркестрації на етапі виконання для отримання та монтування віддалених мікрофронтендів (див. останній пункт для важливих зауважень).
  • Розгортання та версія спрощуються, оскільки весь додаток будується та тестується разом.
  • Продуктивність покращується (у більшості випадків) через меншу кількість запитів до мережі та оптимізовану упаковку. Оптимізація продуктивності також може включати розподіл коду, дозволяючи частинам додатка завантажуватися динамічно під час виконання. Однак, на відміну від мікрофронтендів в час виконання, цей підхід обумовлений технічними факторами та користувацьким досвідом, а не організаційною структурою та обмеженнями.

Чому інверсія контролю важлива в архітектурі мікрофронтендів

Основною метою мікрофронтендів є незалежне розгортання та розробка. Однак коли мікрофронтенди тісно пов'язані з хост-додатком, вони стають важчими для масштабування та модифікації. Інверсія контролю (IoC) дозволяє хост-додатку визначати, як мікрофронтенди інтегруються, а не навпаки.

Замість того щоб диктувати, як кожен мікрофронтенд буде монтуватися, хост-додаток надає чіткі інтерфейси для реєстрації, рендерингу та керування життєвим циклом. Це запобігає тому, щоб мікрофронтенди робили припущення щодо середовища хостингу, зменшуючи проблеми сумісності.

Приклад: Команда "Блог" доставляє функцію блогу в додаток

Уявіть, що ви є частиною команди "Блог" в організації, відповідальної за розробку та інтеграцію функції блогу в один з існуючих додатків організації. Однак ви не є частиною команди, що підтримує цей додаток, і не знайомі з його кодовою базою. Хоча комунікація в вашій команді є гладкою та ефективною, міжкомандна співпраця повільна та неефективна.

Щоб подолати ці труднощі, ви обираєте підхід мікрофронтендів на етапі побудови (MFE). Команда, що підтримує додаток, надала стандартизований інтерфейс, якому ваш блог повинен відповідати.
Цей інтерфейс полегшує інтеграцію, надаючи механізми для реєстрації вашої функції в хост-додатку, доступу до глобального стану та використання спільних функціональностей, таких як сповіщення.

Цей стандартизований інтерфейс для мікрофронтендів (MFE) інкапсульований у спільному компоненті під назвою “Platform.”

pic

Ви додаєте компонент Platform до вашого проєкту і розробляєте свій MFE відповідно до стандартизованого інтерфейсу Frontend, який він надає.

/**  
 * @filaname: blog.tsx   
 * @componentId: learnbit.build-time-mf/frontends/blog  
 */  

import type { Frontend, App } from '@learnbit/build-time-mf.platform';  

export const blog: Frontend = (app: App) => {  
 app.registerRoutes([  
 {  
 path: '/blog',  
 element: ,  
 },  
 ]);  
 app.registerHeaderLinks([  
 {  
 label: 'Blog',  
 path: '/blog',  
 },  
 ]);  
 return app;  
};

Ваш MFE отримує екземпляр app, що надає доступ до API хост-додатку. Це дозволяє вашій команді повністю контролювати, як інтегрується блоговий MFE, даючи змогу змінювати його в будь-який час без необхідності взаємодіяти з кодовою базою хост-додатку.

Крім того, оскільки хост-додаток керує глобальними діями та даними, складність обробки спільних залежностей значно зменшується. Наприклад, додаток може надавати спільну службу сповіщень, що усуває необхідність створення такої служби самостійно. Це мінімізує конфлікти залежностей і забезпечує більш плавний та послідовний користувацький досвід.

/**  
 * @filaname: blog.tsx   
 * @componentId: learnbit.build-time-mf/frontends/blog  
 */  

import type { Frontend } from '@learnbit/build-time-mf.platform';  

export const blog: Frontend = (app) => {  
 app.registerRoutes([  
 {  
 path: '/blog',  
 element: ,  
 },  
 ]);  
};

Хост-додатку достатньо одного імпорт-запиту для включення вашого MFE, без необхідності керувати деталями інтеграції. Ваш MFE зберігає повний контроль над тим, як він інтегрується з додатком.

/**  
 * @filaname: blog.tsx   
 * @componentId: learnbit.build-time-mf/shell-app  
 */  

import { App, type Frontend } from '@learnbit/build-time-mf.platform';  
import { blog } from '@learnbit/build-time-mf.frontends.blog';  
// ...  

const app = new App();  

const frontends: Frontend[] = [blog, ...otherMFEs];  

frontends.forEach((frontend) => frontend(app));  

root.render({app.renderApp()});

“Harmony” — Інверсія контролю на великому масштабі

Цей блог досліджує простий підхід до реалізації інверсії контролю. Для більших проєктів я рекомендую використовувати Harmony framework, який також підтримується командою Bit.

Harmony дозволяє повностекові функції, що називаються аспектами, безшовно інтегруватися в єдину платформу. На відміну від підходу, описаного в цьому блозі, Harmony дозволяє аспектам розширювати API платформи та слоти реєстрації.

Наприклад, аспект — це компонент повного стеку, який може надавати служби аутентифікації для всієї платформи. Це відрізняється від методу, описаного тут, де інтегровані функції або мікрофронтенди не змінюють і не розширюють API платформи.

Прочитайте цей блог, щоб дізнатися більше про Harmony:

[

Знайомтесь з Harmony: практичне рішення для складання єдиних платформ

Ми раді офіційно представити Harmony, мінімалістичну бібліотеку для складання платформ з незалежних…

bit.dev

](https://bit.dev/blog/meet-harmony-a-practical-solution-for-composability-m67z5hlc?source=post_page-----f3f082cd8564--------------------------------)

Перекладено з: Build-Time Micro Frontends: Why Inversion of Control Matters

Leave a Reply

Your email address will not be published. Required fields are marked *