Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Як мікрофронтенди впливають на розробку продукту. Власний досвід

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Всім привіт! Мене звати Максим, я фронтенд-інженер. Останні 7 років живу та працюю в Об’єднаних Арабських Еміратах. Маю досвід у таких сферах як e-commerce, fintech та кібербезпека.

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

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

Що таке мікрофронтенд

Втім, коротко розповім, що таке мікрофонтенди.

Така архітектура на фронтенді імплементується подібно до мікросервісів на бекенді. Тобто ми ділимо звичний монолітний проєкт на незалежні одне від одного частини. Головним інструментом, який дозволяє нам це зробити, є Webpack Module Federation.

Всі незалежні частинки, так би мовити, упаковуються у так званий контейнер, ще один окремий фронтенд. Його відповідальність — хостити та оркеструвати цими незалежними частинами. У більшості випадків, авторизація юзерів будується саме на контейнері, а також дистрибуція даних до мікрофронтендів. Аби налаштувати цю комунікацію, доведеться інтегрувати ще деякі додаткові бібліотеки. Такий підхід у розробці вже використовують такі великі компанії як Amazon, Spotify та Square. І на мою думку, ще більше компаній будуть адаптовувати мікрофнтенди. Якщо ж ви хочете глибше розібратися в темі, то порекомендую подивитись виступи на конференціях Luca Mezzalira. Крім того, у нього також є книга на цю тему.

Як мікрофронтенд впливає на процеси розробки

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

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

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

Планування

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

Розробка

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

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

Тестування

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

Деплоймент

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

Завершення

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

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

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

Дякую за увагу!

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

Стаття хороша. Треба її в dou news бо ведучий мені став нагадувати Задорнова: " Есть свет в конце тунеля, только тунель ... не кончается ".

Дякую, ціквао!
А як шерити дизайн систему написану на тому ж Реакті, якщо інша команда захоче використати Vue?
Чи доведеться кодити загальну базу компонент ще раз?

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

одну й ту саму лібу наприклад редакс, чи потрапить вона двічі в бандл?

Не потрапить, якщо використаєте Weppack Module Federation — там є можливисть уникати повторних завантажень (shared rules). З Import Maps трохи важче, але теж можна. Тільки, як завжди, треба бути обережним із версіями — якщо одна команда використовує в MF1 [email protected], а на хості — ту саму lib, але 1.2.0 — то будуть завантажені обидві )

Чи є даунтайм всього аплікейшену при деплої мікрофронтенду?

Як з будь-яким деплоєм, залежить від стретегії і чим ви обробляєте запити. Якщо бандл сервить проксі у Кубернетісі і використовується звичайна rolling deployment policy, то не бачу чому він має бути.

До тих пір поки хоч хтось сервить бандл воно повинно процювати нормально 24/7.

Підписатись на коментарі