Comments 21
Ещё одной важной проблемой микрофронтов является производительность. Бьёт оч сильно по ряду метрик ж
А можете подробнее объяснить насчет проблемы с метриками?
у нас микрофронтовость может быть реализована несколькими вариантами:
- билдтайм
- рантайм
- SSI
Если мы говорим про билдтайм, то больше похоже на то, что другие фронты, как либы интегрируются в твой бандл. Сложно назвать это "микрофронтовостью", однако такой подход имеет право на жизнь. Просто добивается бандл, но мы тут хоть немного можем влиять на оптимизацию.
Если мы говорим про рантайм (например module federation) то появляется лишняя асинхронность, которая может повлиять на web vitals, ведь ты не можешь гарантировать скорость ответа за новым чанком с JS который повлияет на рендер
Если мы говорим про рантайм и SSI ты не контролируешь, что другая команда вставила в свой микрофронт, а значит твой перформанс больше не твой, а общий. Они могут обмазаться библиотеками, сложными вычислениями и прочим, ты это не контролируешь. Так же обвязка, которая позволяет сделать модули, асинхронными не является "бесплатной". Хотя иногда можно подумать, что это экономия на спичках.
Мой опыт.
Проблема у этого в том, что каждая команда своего микрофронта будет преследовать свои метрики (бизнесовые) и для них их метрики в приоритете, особенно при учете наличия беклога и ограничений по ресурсам команды.
Вообще вся проблемы микрофронтов в меньшей мере технические, а в большей именно организационные.
Так же есть проблема конфликта версий используемых библиотек в разных микрофронтах, что может привести к крашу всего приложения на клиенте.
Еще не стоит забывать, что один из микрофронтов может переставть отвечать и это должно быть учтено, как со стороны дизайна и клиентского пути, так и со стороны тестирования и фоллбеков
Еще забыл. за частую микрофронты — это забыть про дедупликацию. Module federation может это делать, но с учетом, что все добросовестно указали свои зависимости. Но также из-за этого treeshaking не допустим, т. к. ты не знаешь, какой кусок этой либы нужен в другом микрофронте.
Роман, ну что вы сразу на грабли.
Можно же оптимизировать =)
Не написал в этой статье - напишет в следующей по просьбам желающих
А как происходит общение двух микрофронтендов, например, на React и Angular, если откинуть вариант гнать сообщения через бэкенд?
Данную проблему можно решить при помощи Module Federation. Два проекта разворачиваются на двух разных серверах и с помощью плагина moduleFederation в хостовом приложении добавляются пути до файлов remoteEntry для разных приложений
если планируется использовать разные фреймворки\технологии работы с фронтом, то проще использовать подход eventbus и общаться сообщениями через какой-то общедоступный узел (хоть body). Это даст тебе слабосвязанность и фреймворк агностность (хз есть такое слово или нет))).
Но при этом я бы (да и всех, кого знаю) не советовал на одном продукте использовать разные фреймворки. Производительность такого приложения пойдет ко дну
Основная проблема как по мне не подсвечена. а как же изолирование приложений? если у вас допустим есть приложение главной страницы которое ресетит стили и есть часть другого приложения которому ресет стилей не нужен? тоже самое касается кода.
по работе со сторами я согласен что это проблема - но не такая большая. создаём стор хранения всех модулей и общаемся с ними через события не сообщая напрямую приложению что то а только лишь эфектами. тем самым нужные части приложения подхватят эти события. само собой слой стора должен быть обновляемый и доступен для редактированию всем членам команды и это тот самый 5 пункт. а так же очень низкая отказоустойчивая.
Ресет стилей можно сделать точно также, как если бы ресет происходил в рамках одного приложения. Разбиение на микрофронты не влияет на решение
ну как же не влияет - первое приложение требует ресета стилей второе нет. вся суть проблемы что если одно приложение использует другое то они оба получат эти стили. в чанке обоих это будет существовать. и номральной изоляции кроме как вебкмпонентов и iframe в данный момент не существует)
Ну тут проблема не микрофронтами, это то же самое, если один кусок одного приложения требует ресета, а в другой кусок этого же приложения - нет
Со своей стороны могу сказать, что немного не согласен, что микрофронтовая архитектура лучше монолитной. Тут, как и в любом архитектурном решении "it depends". Каждый случай надо рассматривать индивидуально. Зависит от компании и ее организации (часто организация определяет архитектуру проектов), от самого проекта и требований по нему.
За частую, хорошо структурированный код в монолите будет лучше, чем множество отдельных частей сайта, разбросанных по отдельным "микрофронтам". Качественнее и проще тестируемость. Меньше бандл. Проще контроль за кешами. Ресурсов монолиты жрут меньше (если в целом посмотреть).
Микрофронты дают гибкость при росте команд. Когда есть четкое разделение зон ответственности (иначе канибализация и постоянны терки между командами). Быстрее time to market за счет снижения области тестирования. Проще интегрировать новых людей т.к. в меньшее кол-во кода и зону ответственности их надо погружать.
Работал я одно время в большой компании с кучей команд и с большими проектами с Single-SPA, и согласен со многими нюансами. Сейчас в новой компании у нас есть маленькая команда и большой монолит и тут стали подумывать о микрофронтенде но я пока отговариваю так как в нашем случае это мне кажется это трата сил и времени. В крайнем случае думал разбить монолит например на страницы и вынести в отдельные репы и подлючать через react-lazy, ну и они будут использовать общий стор и нашу библиотеку ui. Как вы думаете это жизнеспособный вариант разделение монолита для улучшения производительности и возможно для переиспользования этих частей монолита в других проектах?
зависит от того как будут чанки собираться и на чём всё это будет работать. В целом решение вполне рабочее.
извини, но вообще ничего не скажу, чтобы не сказать глупости т.к. не знаю вашу текущую архитектуру, текущие проблемы поставки\разработки\поддержки, где именно узкое горлышко перформанс (и какие именно метрики туда вкладываются), кто ваш клиент (и его технические ограничения), а самое главное "разделить монолит что бы что?" (блин, Дорофеев покусал). Т.е. что именно хочется решить этим рефакторингом архитектуры. Ведь это может потянуть за собой переделку тестов, пайплайнов...
Я бы предложил первым делом понять ограничения проекта, с чем они связаны и как это аффектит на вашего пользователя. Вдруг вы смотрите на перформанс по 99 перцентилю и пытаетесь его решить, а там проблема при попадании на холодный кеш.
При разбивании так же я бы приложил учитывать, что это за тип приложения (какой нить бекофис или клиентское приложение) т.к. в какой-то момент есть шанс того, что пользователь через все эти react-lazy так или иначе выкачает себе полностью все. Но при этом обвязки в виде асинхронности не бесплатны.
Переходите на микрофронтовую архитектуру