Мікрофронтенди: коли вони справді потрібні

Не рішення, а компроміс

Мікрофронтенди часто обирають за інерцією — «раз бекенд у нас мікросервісний, хай і фронт буде таким же». На практиці це архітектурне рішення з реальною ціною: дублювання залежностей, ускладнена маршрутизація, необхідність синхронізувати дизайн-систему між командами.

Мікрофронтенди виправдані там, де кілька незалежних команд справді працюють над різними частинами одного продукту і їм важливо деплоїтися окремо одна від одної, не чекаючи релізного циклу сусідів. Детальніше про суміжний підхід можна прочитати в матеріалі «Розбираємося з View Transitions API».

Коли краще залишитися на моноліті

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

Перш ніж розбивати застосунок, варто чесно відповісти на запитання: чи вирішує розділення організаційну проблему (координація команд), чи ми просто копіюємо модний патерн. Якщо проблема технічна, а не організаційна, зазвичай є дешевші способи її вирішити. Ці ідеї перегукуються з темами «Як працює Virtual DOM і навіщо він потрібен» та «Патерн CQRS для складних доменів».