Розуміння мікрофронтендів:

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

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

Переваги мікрофронтендів:

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

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

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

4. Швидша розробка: Автономність, яку забезпечують мікрофронтенди, призводить до пришвидшених циклів розробки. Кожен сервіс знаходиться в своєму репозиторії, що дозволяє командам працювати незалежно, використовуючи спеціалізовані навички та інструменти для пришвидшення доставки функціональностей.

Форми мікрофронтендів:

Архітектура мікрофронтендів пропонує гнучкість у тому, як організовуються та співпрацюють проекти. Ось три найбільш поширені форми:

1. Монорепозиторій: Усі мікрофронтенд-проекти зберігаються в одному репозиторії. Хоча це схоже на початкову проблему великої кодової бази, така організація має переваги, такі як спрощена співпраця та узгоджені стандарти в межах проектів.
2. Мульти-репозиторій: Кожен мікрофронтенд-проект має свій окремий репозиторій, що дає кожній команді автономію в розробці та деплої. Немає центрального базового проекту, і всі проекти мають рівні права.
3. Метарепозиторій: Схожий на мульти-репозиторій, але з інтегрованими окремими мікрофронтендами в одному основному репозиторії. Ця інтеграція може використовувати методи, такі як iframes або скрипти для включення інших проектів. Метарепозиторій дозволяє централізовано керувати та рендерити мікрофронтенди.

Інтеграція:

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

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

Налаштування мікрофронтенду:

Для потреб цієї статті ми припускаємо, що у нас є PHP монолітний батьківський репозиторій і фронтенд фреймворк на JavaScript (React).

Примітка: Існують різні способи налаштування та інтеграції, це один з багатьох варіантів.

Щоб продемонструвати наш процес інтеграції, розглянемо тестовий сервіс в адміністративному дашборді. Метою є безперебійне інтегрування мікрофронтенду в нашій кодовій базі PHP, використовуючи зібрані скрипти JavaScript і CSS, які отримуються при складанні або збірці вашого додатку, або ж коли додаток розгорнуто і працює, це CSS і JS ресурси, які браузер завантажує для рендерингу сторінки.

Налаштування мікрофронтенду:

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

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

Конфігурація Webpack prod.js

Конфігураційний файл Webpack dev.js

Конфігураційний файл Webpack config.js

Конфігураційний файл Webpack common.js

Prod js містить конфігурації для продакшн середовища. Dev js містить конфігурації для середовища розробки, а common js містить конфігурації, спільні для обох середовищ. config js об'єднує все разом.

Після успішної конфігурації, виконання команди збірки створить файл manifest.json у кореневій директорії dist. Цей файл манифесту визначає очікувані файли скриптів, що є важливими для деплою на платформи типу AWS Amplify.

Налаштування моноліту:

Моноліт слугує базовим додатком, де ми створюємо div елемент для рендерингу нашого React додатку. Маршрутизація управляється з боку PHP, що позбавляє нас необхідності використовувати такі бібліотеки як react-router-dom.

Почніть з визначення PHP маршрутів, потім створення відповідних контролерів.

Визначення маршруту PHP

Завантажте змінні середовища з боку PHP, щоб включити файли скриптів з мікрофронтенду.

Наприкінці налаштуйте ваш blade файл для рендерингу скелету HTML кореневого div, і id цього div повинно збігатися з id в кореневому HTML файлі вашого мікрофронтенду. За замовчуванням у React використовується id='root', тому ви можете додати це до вашого div в PHP blade файлі, і це буде використовуватися для інжекції скрипта.

Налаштування Blade PHP

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

Інші міркування

Маршрутизація:

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

Використання умовних операторів дозволяє співвідносити маршрути для рендерингу кожної сторінки (компонента) залежно від поточного маршруту батьківського додатку (моноліту).

Аутентифікація:

Аутентифікація є важливою міркуванням, особливо коли мова йде про мережеві виклики в мікрофронтенді та потребу в токенах для аутентифікованих маршрутів.
Поки мікрофронтенд може реалізувати власний механізм аутентифікації, дублювання процесу входу є непрактичним. Тому ми розробили метод передачі токенів від моноліту до мікрофронтенду.

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

Приймаючи ці підходи, ми забезпечуємо ефективну маршрутизацію та безперебійне проходження аутентифікації в нашій архітектурі додатку.

Висновок:

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

Популярною альтернативою є використання iframes. У цьому випадку маршрути PHP налаштовуються подібним чином, але замість того, щоб рендерити React додаток всередині div, використовується iframe. Цей iframe забезпечує комунікацію між двома додатками через Post Message взаємодію, що дозволяє ефективно співпрацювати від батьківського додатку до дитини iframe.

Також мікрофронтенд можна пакувати при кожній збірці як статичний ресурс, що зберігається на CDN, і його можна легко обслуговувати, коли моноліт здійснює виклик. Це був би більш рекомендований підхід, оскільки він гарантує швидший час завантаження, особливо коли розташування ресурсу CDN близьке до користувача (Edge computing). Я опублікую статтю з цього питання в майбутньому.

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

Це відео на YouTube буде корисним, зокрема, для налаштування додатку React Micro Frontend, з поясненням кастомної конфігурації webpack. https://www.youtube.com/watch?v=zb4WQaxdvLA&t=2568s&ab_channel=techRoute

Посилання:

• https://www.toptal.com/front-end/micro-frontends-strengths-benefits
• https://www.turing.com/blog/micro-frontends-what-are-they-when-to-use-them/#:~:text=Micro%20frontends%20apply%20the%20same,offer%20to%20their%20backend%20counterparts.

Перекладено з: Maximizing Agility: Seamless Microfrontend to Monolith Web Application Integration