Комментарии 25
Спасибо за интересную статью!
Представьте несколько абсолютно разных страниц, которые написаны на разных фреймворках, но объединены в одно приложение. Это и есть MFE, или микрофронтенды.
Странное определение
А если у меня веб приложение на одном Vue, и в нем две слабо связанные части которые независимо пишут две команды - это не микрофронтенды?
Микрофронт - это несколько репозиториев (если утрировать)
Вы используете один репозиторий и потенциально в будущем могут возникнут проблемы внутри релизов. Иногда при релизе нужно оставить старый функционал одной части и новый другой. У вас этой проблемы может и быть, но когда проект разрастается и разработчиков становится больше, тогда может понадобиться разделять релизные циклы
Вот, кстати, прекрасный пример как делать не надо. Функциональности с гулькин нос, а тормозит как якорь из урана.
один общий store, который помогает нам обмениваться между компонентами, страницами и т. д., а также хранить информацию из базы данных;
А вы не пробовали не класть все яйца в одну корзину? Ну там написать полноценную (не тупую) модель предметной области и тд.
в монолите практически нет изоляции, и все части сильно зависят друг от друга — если что-то произойдёт с одной частью, то и другие тоже встанут.
Похоже ваш фреймворк не умеет адекватно обрабатывать исключительные ситуации. Может ну его?
Представьте несколько абсолютно разных страниц, которые написаны на разных фреймворках, но объединены в одно приложение.
Представьте, что у вас в каждой комнате находится стиральная машина, унитаз, раковина, холодильник, плита, духовка, чайник, барабанная установка, и памятник барону Мюнхгаузену.
О, как часто я встречал в разных компаниях таких критиков. Которые приходят и говорят: "Все отстой, все надо переделывать. Бизнес, подожди, у меня тут свои проблемы, давай ты потратишь деньги на то, что мне надо все переписать, к черту твои цели и прибыли от новых функций". Правда, часто за ними тоже все приходится переделывать.
Зар спасибо Вам за статью!
Всё систематизировано, описано понятным языком и вообще, именно таких статей где коротко, по существу и на актуальную тему, сейчас очень не хватает на хабре.
Допускаю это:
есть несколько команд, которые делают одно дело и постоянно спотыкаются друг об друга, конфликтуют;
Может там, где спотыкаются, выделить новую команду?
И почему перестанут конфликтовать на общем функционале, он же останется?
Кстати, конфликты и у одной команда бывают.
Ну ведь команда не появится из воздуха, да и платить им надо. Да и распределение ресурсов существующих команд тоже не поможет, иначе они со своими задачами не справятся((
| И почему перестанут конфликтовать на общем функционале, он же останется?
Не перестанут, доработки в библиотеку компонентов или аналогичные модули (которые используют вообще все) всегда придется согласовывать и вносить с оглядкой на обратную совместимость.
Будет меньше заморочек.
Вот есть команда А и Б, есть у этих команд свои модули, есть общий ui-kit, вынесенный в отдельный npm пакет.
Команде А нужно что - то поменять в одном из компонентов kit-a, вносят они эту правку, и оказывается, что в модуле команды Б что - то сломалось. Команда Б об этом узнает только если обновит версию kit-a, может это вообще не понадобится никогда, если модуль команды Б это легаси, которое лениво ковыряют. Но даже если нет - они просто откатят версию кита, отправят команде А багрепорт, и будут дальше работать над своим функционалом.
В монолите, после деплоя доработки командой А, на какое - то время всё встанет у обоих команд.
Преимущества становится еще более очевидными, если допустить, что команд не 2, а 10 :)
есть несколько команд, которые делают одно дело и постоянно спотыкаются друг об друга, конфликтуют;
неужели нельзя это решить административными способами?
Команда Х - вот, разрабатывайте пожалуйста компонент\страницу Х. А вы команда Y - пожалуйста, разрабатывайте компонент\страницу Y. И не мешайте друг-другу!
У кого возникнет пересекающиеся вопросы - назначте совещание - обсудим.
На митингах понятное дело не весь базар присутсвует, а только лиды от каждой команды, которые уже делегируют инфу своим падаванам.
Разговоры разговаривать это прекрасно. Можно и год общаться по поводу того, в чьей ответственности та или иная функциональность. Как бы не забываем, любой проект в большой компании это бюджеты и возможности продвижения себя или команды. Большая компания это всегда дофига политики и интересантов того или иного. Спасают только жёсткое разграничение ответственности, правила, а так же некий внешний контроль, желательно автоматизированный.
На моей практике приложение с микрофронтендом грузилось дольше чем монолит. Может было что-то неправильно спроектировано или у микрофротов есть такая проблема?
Что сперва инициализируются все микрофронты, а затем уже отображаются
Микрофронты абсолютно не про перформанс для клиента. Даже больше, ты как часть становишься зависим от многих. А они приследуют свои бизнес метрики, потому влияние на твой микрофронт это последнее, что беспокоит сторонние команды. Микрофронты - это про оптимизацию процессов поставки и разработки продуктов.
юзаю больше года на проекте module federation, в целом всем устраивает.
Все внятно и дотсупно!
Микрофронтенды — универсальное решение всех проблем или просто удобный подход?