Зміст[Сховати][Показати]
Ідея мікросервісів нещодавно привернула багато уваги, і багато компаній використовують її, щоб позбутися великих, монолітних серверних програм.
Пройти той самий шлях із інтерфейсом все ще є проблемою для багатьох компаній, навіть якщо цей розподілений спосіб побудови серверної сторони веб-додатків є більш-менш надійним з точки зору дослідження та виконання.
Через тісну залежність моноліт на стороні клієнта зазвичай ускладнює інтеграцію нових функцій, впровадження нових технологій і масштабування окремих компонентів.
Ці та інші проблеми спонукали розробників інтерфейсу досліджувати використання мікросервісів.
У результаті була розроблена абсолютно нова архітектурна стратегія, відома як microfrontend, для створення зовнішнього рівня веб-сайтів і веб-додатків.
Термін вперше був використаний у 2016 році, і відтоді він привернув багато уваги заради доброї справи.
Ця стаття дасть загальне розуміння того, що таке мікроінтерфейси та проблеми, які вони вирішують. це працює, а також плюси та мінуси.
Вступ до архітектури мікроінтерфейсу
Сучасний метод інтерфейсної розробки, який називається мікроінтерфейсною архітектурою, поділяє a веб-додаток на невеликі незалежні частини.
Для кінцевого користувача ці частини здаються єдиним цілим, навіть якщо вони були сконструйовані окремо, а потім зібрані разом.
З тією різницею, що мікроінтерфейси стосуються клієнтської, а не серверної сторони онлайн-рішень, обґрунтування, що лежить в їх основі, ідентичне обґрунтуванню мікросервісів.
Створення складних веб-продуктів має найбільший сенс за використання мікроінтерфейсу.
Мікроінтерфейси, на відміну від більш традиційного моноліту інтерфейсів, дозволяють багатьом командам окремо співпрацювати над різними програмними проектами.
Завдяки цьому архітектурному дизайну програмісти можуть створювати веб-програми швидше та з більшою масштабованістю та зручністю обслуговування.
Простіше кажучи, кожен мікроінтерфейс — це лише фрагмент коду для окремого компонента веб-сторінки.
Ці функції контролюються окремими командами, кожна з яких спеціалізується на певній галузі чи меті.
Монолітна проти мікросервісної та мікроінтерфейсної архітектури
Подумайте про переїзд. Вам буде простіше організувати все в кілька маленьких коробок із професійними написами та перемістити кожну окремо чи запакувати всього персоналу в одну величезну коробку та перевезти її на нове місце?
Очевидне рішення є.
Ця аналогія порівнює дві різні архітектури веб-додатків, моноліти та мікросервіси (також відомі як мікроінтерфейси).
Монолітна архітектура
Можливо, ви зможете пригадати «старі добрі часи», коли повну програму створювали як єдине ціле. Такий метод називається моноліт, що є старим терміном для великої кам'яної брили.
Це має сенс.
Монолітні системи мають взаємозалежні елементи. Тому, якщо ви захочете щось змінити або додати нову функцію, цілком можливо, що вся система може вийти з ладу.
Незважаючи на те, що він застарів, іноді він все ще існує. Так, ми знаємо про ваш поточний вираз.
Концептуальний поділ кодової бази на два різні компоненти — інтерфейс (на стороні клієнта) і сервер (на стороні сервера) — став неминучим із розвитком нових технологій і ускладненням програмних продуктів.
Зараз найпопулярнішим методом роботи є поділ проблем між рівнем презентації, з яким взаємодіє кінцевий користувач, і всім, що відбувається у фоновому режимі.
Для цього потрібні дві команди розробників програмного забезпечення: фронтенд-група розробляє візуальні компоненти, а бекенд-група розробляє веб-сервіси, бізнес-логіку, доступ до даних, інтеграцію тощо.
Однак, незважаючи на цей поділ, ця стратегія все ще залишається монолітною за своєю природою.
Основна зміна полягає в тому, що ми тепер маємо два значні блоки коду — інтерфейс і сервер — замість однієї величезної програми. Монолітні архітектури не повинні бути жахливими; вони мають кілька переваг, в тому числі
- Проста і швидка розробка для невеликих програм з єдиною базою вихідного коду та дуже простим дизайном;
- Тестування та налагодження дуже прості, оскільки весь код знаходиться в одному місці, що полегшує групі відстеження потоку запитів і виявлення помилок;
- На ранніх стадіях розробки програми витрати менші, оскільки ані витрати на інфраструктуру, ані витрати на розробку не виникають, доки не додаються нові функції.
Недоліки цієї стратегії відображені в
- Обмежена гнучкість розгортання – командам доводиться чекати, якщо над проектом працює лише кілька з них, і щоразу, коли ви оновлюєте код, потрібне нове розгортання;
- Запровадження нових технологій є складним завданням, оскільки для цього потрібно переписати значну частину, якщо не весь проект.
- Коли кількість розробників збільшується, система коду стає тісно пов’язаною, складною та важкою для управління та розуміння.
- Організаційні питання – кожен член команди повинен використовувати однакову версію бібліотек і повідомляти про будь-які зміни, якщо багато команд працюють над монолітним проектом.
- Занепокоєння щодо масштабованості – оскільки компоненти проекту взаємопов’язані, їхнє масштабування окремо створює труднощі, що призводить до значних простоїв і вищих витрат.
- Новим членам команди може бути важко зрозуміти складну логіку проекту, особливо якщо інженери, які спочатку над ним працювали, більше не працюють.
Розробка мікросервісів та їхніх близьких родичів, а також мікроінтерфейсів вирішила основні проблеми монолітних систем.
Архітектура мікросервісів
Архітектурний метод, відомий як мікросервіси, дозволяє створювати багато слабко пов’язаних і незалежно розгорнутих менших компонентів або служб, які складають серверну частину програми.
Кожна служба має власну кодову базу, конвеєри CI/CD, процедури DevOps і процеси для їх запуску.
Ви можете побачити, що монолітна бекенд-команда розділена на окремі команди, подивившись на зображення вище.
Кожен окремо зосереджується на різних аспектах програми (таких як служба продукту, служба пошуку та служба оплати).
Зв’язок між службами відбувається за допомогою встановлених протоколів, відомих як API, наприклад полегшеного протоколу REST API, який використовує синхронні шаблони запитів і відповідей.
Іншим варіантом є використання асинхронного зв’язку за допомогою такого програмного забезпечення, як Kafka, яке пропонує комунікаційні структури та події публікації/підписки.
Мікросервіси інтегруються з інтерфейсом через бекенд для служби інтерфейсу (BFF) або шлюз API через мережу. BFF пропонує індивідуальний API для кожного клієнта, тоді як шлюзи API надають єдину точку доступу для колекції мікросервісів.
Але навіть з автономними компонентами серверної частини та всіма перевагами, які вони надають, зовнішня частина залишається монолітом.
Тому тут корисні мікроінтерфейси.
Архітектура мікроінтерфейсів
Подібно до мікросервісів, де слабко пов’язаними компонентами керують кілька команд, мікроінтерфейсна архітектура застосовує концепцію до браузера.
Ці інтерфейси користувача веб-додатків дотримуються такої структури, яка складається з дещо автономних компонентів.
Команди також створюються на основі потреб клієнта або випадків використання, а не на певному досвіді чи технології.
Отже, команди задіяні в мікросервісах і мікроінтерфейсних проектах.
- вертикально розрізаний — оскільки над одним проектом також працюють інтерфейсні розробники, експерти з даних, бекенд-інженери, інженери з контролю якості тощо, вони створюють свої функції з інтерфейс користувача до баз даних; і
- міжфункціональний – кожен член команди вносить свій досвід у групу.
Команди також можуть вибрати технологічний набір, який найкраще відповідає їхньому конкретному напрямку бізнесу.
Одна команда може використовувати React для програмування свого фрагмента. Інша команда створює нову версію Angular. Vue.js є одним із таких прикладів.
Мікроінтерфейси використовуються разом із відповідними мікросервісами для вирішення проблем, які зазвичай виникають у команд розробників із монолітами. Стратегія пропонує наступні переваги.
- Технологічна свобода: інженери Frontend можуть вибирати альтернативні фреймворки JavaScript, середовища виконання та цілі стеки технологій залежно від потреб компанії. На додаток до застарілої архітектури можна застосувати нову структуру.
- Можливий більший ступінь гнучкості, оскільки кожен мікроінтерфейс є самодостатнім і може розроблятися, тестуватися, розгортатися та оновлюватися окремо. У результаті, якщо одна команда працює над функцією та виправила помилку, а інша команда має додати власну функцію, їм не потрібно чекати, поки перша команда виконає своє завдання.
- Автономні команди та системи: кожна команда продукту, а отже, і кожна функція, можуть функціонувати з невеликою залежністю від інших, що дає змогу продовжувати роботу, навіть якщо найближчі компоненти недоступні.
- Кілька менших кодових баз: кожен із мікроінтерфейсів матиме власну, більш керовану, меншу кодову базу. Менше людей зосереджуватимуться на конкретному компоненті інтерфейсу користувача, спростять перевірку коду та покращать загальну організацію.
- Просте масштабування програми: ще однією перевагою мікроінтерфейсів є можливість масштабувати кожну функцію окремо. На відміну від монолітів, де всю програму потрібно масштабувати кожного разу, коли додається нова функція, це робить увесь процес більш ефективним з точки зору як часу, так і грошей.
Як працює мікроінтерфейс?
Як ми зазначали раніше, команди організовані вертикально всередині архітектури мікроінтерфейсу, що означає, що вони розділені знаннями домену або цілями та несуть відповідальність від початку до кінця за конкретний продукт.
Він може мати один або два серверні мікросервіси, а також невеликий інтерфейс. Давайте більш детально розглянемо характеристики цього візуального елемента, взаємодію з іншими компонентами інтерфейсу користувача та вбудовування в домашню сторінку.
Мікроінтерфейс може бути
- цілу сторінку (наприклад, сторінку з інформацією про продукт) або
- розділи сторінки, якими можуть користуватися інші команди, наприклад верхні, нижні колонтитули та рядки пошуку.
Ви можете розділити великий веб-сайт на кілька типів сторінок і передати кожен тип певному персоналу для роботи.
Проте кілька компонентів часто зустрічаються на багатьох сторінках, наприклад верхні, нижні колонтитули, блоки пропозицій тощо. Блок пропозицій, наприклад, можна включити на домашню сторінку, сторінку з інформацією про продукт або навіть сторінку оформлення замовлення.
По суті, команди можуть створювати елементи, які інші команди можуть використовувати на своїх сторінках.
Однак мікроінтерфейси можна розгортати окремо як різні проекти на відміну від компонентів, які можна використовувати повторно.
Все це звучить фантастично, але для створення єдиного інтерфейсу сторінки та фрагменти потрібно якимось чином поєднувати.
Для цього потрібна зовнішня інтеграція, яку можна здійснити за допомогою різноманітних стратегій, включаючи маршрутизацію, композицію та зв’язок (див. графік вище).
Маршрутизація
Коли для доступу до сторінки, що належить іншій команді, потрібна служба зі сторінки, яка контролюється однією командою, маршрутизація корисна для інтеграції на рівні сторінки.
Кожен мікроінтерфейс обробляється як односторінкова програма. Для забезпечення маршрутизації можна використовувати прості HTML-посилання.
Користувач може змусити браузер завантажити цільову розмітку з сервера та замінити поточну сторінку новою, натиснувши гіперпосилання.
Оболонка додатка — це мінімум HTML, CSS і JavaScript, який забезпечує інтерфейс користувача. Навіть якщо запитувані на сервері дані вмісту все ще очікують, користувач одразу отримує статичну відображену сторінку. Центральна оболонка програми служить батьківською програмою для односторінкових програм, створених різними командами.
Незалежно від бібліотеки чи фреймворку, який використовується, метафреймворки дозволяють об’єднувати різні сторінки в одну.
Склад:
Композиція — це процес упорядкування фрагментів у відповідних місцях на сторінці. У більшості випадків команда, яка розгортає сторінку, не відразу отримує вміст фрагмента.
Натомість він розміщує покажчик місця заповнення або маркер там, де має бути фрагмент у розмітці.
За допомогою іншого процесу складання завершується остаточне складання. Композицію можна розділити на дві основні категорії: на стороні клієнта та на стороні сервера.
Композиція на стороні клієнта: веб-браузер використовується для створення та редагування розмітки HTML. Кожен мікроінтерфейс має можливість змінювати та відображати свою розмітку окремо від решти сторінки.
Веб-компоненти, наприклад, дозволяють виконувати цей тип побудови.
План полягає в тому, щоб перетворити кожен фрагмент на веб-компонент, який можна незалежно встановити як файл a.js, після чого програми зможуть завантажувати та відтворювати їх у місцях, призначених для них у макеті теми.
Веб-компоненти залежать від HTML і DOM API, які можуть використовувати інші зовнішні фреймворки, а також від стандартного методу надсилання та отримання даних через властивості та події.
Композиція на стороні сервера: у такому дизайні елементи інтерфейсу об’єднуються на сервері, що призводить до надсилання повністю сформованої сторінки на сторону клієнта, що прискорює завантаження.
Збірка часто виконується окремою службою, яка знаходиться між веб-браузером і веб-серверами. CDN є одним із екземплярів послуги (мережа доставки вмісту).
Ви можете вибрати один або комбінацію двох, залежно від ваших потреб.
Шаблони зв'язку мікроінтерфейсу
Архітектура мікроінтерфейсу працює найкраще, коли між різними компонентами практично немає взаємодії. Мікроінтерфейси іноді потребують спілкування один з одним і обміну інформацією. Ось кілька потенційних моделей, які можуть призвести до цього.
- Працівники мережі: онлайн-працівник — це механізм, який дозволяє веб-вмісту запускати JavaScript у фоновому режимі незалежно від інших сценаріїв і без впливу на швидкість сторінки. Для кожної мікропрограми буде надано унікальний робочий API. Ця перевага полягає в тому, що трудомістку роботу можна виконувати в іншому потоці, дозволяючи потоку інтерфейсу користувача продовжувати роботу без уповільнення або зупинки.
- Випромінювач подій: У цьому випадку багато компонентів спілкуються один з одним, прослуховуючи та реагуючи на будь-які зміни стану в компонентах, на які вони підписані. Інші мікроінтерфейси, які підписалися на цю подію, відповідають, коли мікроінтерфейс запускає цю подію. Емітер подій, який було введено в кожен мікроінтерфейс, робить це можливим.
- Зворотні виклики та реквізити: у цьому розділі ви визначаєте батьківський компонент і дочірні компоненти. Комунікація організована в деревоподібну структуру. Батьківські компоненти використовують властивості для передачі даних як функцій вниз по дереву компонентів до дочірніх компонентів. У свою чергу, дитина може ефективно попереджати батьків, коли щось відбувається в її стані, відповідаючи на зворотні виклики. React використовує цей режим.
Плюси інтерфейсу Micro
Розвиток у швидко автономних командах
Незалежна команда може створити кожну частину веб-програми або веб-сайту за допомогою методу мікроінтерфейсу.
Кожна команда повністю автономна, що означає, що вона відповідає за весь цикл розробки компонентів, від концепції до випуску та пост-продакшну.
Крім того, це означає, що різні команди можуть без проблем співпрацювати, одночасно працюючи над одним проектом.
Таким чином, цикли випуску є значно швидшими, ніж це було б із зовнішніми монолітами.
Менші кодові бази окремих мікроінтерфейсів призводять до чистішого коду
Монолітні інтерфейси мають великі, громіздкі кодові бази, які з часом стають все більш хаотичними та складними для керування.
Мікроінтерфейси вирішують цю проблему. Вихідний код кожного мікроінтерфейсу легше керувати, оскільки він менший, простіший і компактніший.
Як наслідок, загальне веб-рішення виграє від чистішого коду.
Покращена стабільність програми через слабке з’єднання
Веб-рішення рідко можна розділити на повністю незалежні частини. Отже, мікроінтерфейси спілкуються один з одним.
Проте кожен зв’язок між компонентами є важливим, незважаючи на слабкий зв’язок.
Збій одного компонента практично не впливає на роботу всіх інших компонентів, що забезпечує підвищену стабільність веб-рішення.
Тестування окремих функцій стало простіше
Ця перевага є результатом характеристик мікроінтерфейсів. Завдяки цьому архітектурному дизайну клієнтська сторона веб-рішення є модульною, і кожен модуль є автономним.
У результаті команді легше оцінити невелику частину інтерфейсу користувача окремо, ніж тестувати величезний моноліт.
Зменшений розмір комплекту веде до швидшого завантаження сторінки
Однією з основних причин затримки часу завантаження в багатофункціональних монолітних веб-системах є розмір пакета JavaScript. З іншого боку, підхід мікроінтерфейсу полегшує скорочення часу завантаження сторінки.
Браузеру не потрібно постійно завантажувати непотрібний код, оскільки веб-сторінка складається з кількох крихітних пакетів. В результаті продуктивність сторінки та час завантаження збільшуються.
Технологічна незалежність
множинний інтерфейсні фреймворки може використовуватися розробниками для створення єдиного онлайн-рішення з архітектурою мікроінтерфейсу.
Оскільки кожен компонент є автономним, його можна створити за допомогою будь-якої технології, яка найкраще відповідає завданням команди.
Природно, програмістам слід бути обережними при виборі фреймворків для програмного проекту, за який вони відповідають, і консультації з іншими командами все одно настійно рекомендуються.
Однак існує нульова ймовірність того, що ви будете змушені використовувати застарілу структуру протягом усього терміну служби програми.
Мінуси Micro Frontend
Тестування комплексного веб-рішення в повному обсязі
Тестувати різні модулі веб-рішення легко, якщо воно використовує архітектуру мікроінтерфейсу. Однак це відрізняється від оцінки веб-програми в цілому.
Перш ніж продовжити, переконайтеся, що всі частини працюють належним чином. Це може бути важко, оскільки мікроінтерфейси працюють незалежно та мають окремі процеси доставки.
Дорогі початкові інвестиції
Розробка мікроінтерфейсу зазвичай вимагає значних фінансових витрат. Збирати та підтримувати багато фронт-енд команд дорого.
Крім того, вам знадобиться керівний персонал, щоб організувати роботу, переконатися, що все скоординовано, і гарантувати відмінну комунікацію команди.
Складність розробки та розгортання
Процедури розробки та розгортання можуть стати більш складними в результаті дизайну мікроінтерфейсу.
Наприклад, незалежні команди розробників, які працюють над одним проектом, можуть захаращувати рішення занадто великою кількістю компонентів, що може спричинити проблеми на етапі розгортання.
Правильна збірка всіх модулів і плавна їх інтеграція в загальну схему також не завжди проста; ця робота зазвичай потребує глибокого розуміння всіх залежностей.
Проблеми підтримки узгодженості в користувацькому досвіді
Підтримувати узгоджений інтерфейс користувача складно, коли команди працюють окремо над кількома частинами програмного забезпечення.
Веб-рішення має бути спільним для всіх розробників проекту. Інакше на дорозі може виникнути багато протиріч.
Висновок
Мікроінтерфейси, сучасний архітектурний дизайн, можуть значно підвищити продуктивність великомасштабних проектів веб-розробки на основі мікросервісів.
Це дозволяє програмістам розділити повне рішення на окремі частини, які можуть бути створені кількома автономними командами. З цього випливають численні переваги, зокрема швидше впровадження функцій, легше тестування окремих модулів і більш плавне оновлення.
Але є деякі труднощі і з мікроінтерфейсами.
Комплексне тестування програми, наприклад, може бути складним завданням.
Крім того, через те, що потрібна велика команда інженерів і адміністраторів, проекти мікроінтерфейсу дуже дорогі.
Отже, перш ніж прийняти рішення, ви повинні взяти до уваги всі складові вашого бізнес-кейсу.
Володимир Чамай
Я чомусь не розумів, за яким принципом працює зв'язок між окремими компонентами на фронтенді. Я не розумію, як ви хочете з’єднати компоненти, створені в різних фреймворках. У статті про це нічого не сказано. Система подій і слухачів мені здається пеклом на землі. Як нам це уявити?