Комментарии 7
Хороший кейс, спасибо за статью, плюсанул. Смутил только вебпак в 2026, рассмотрите вариант переезда на rsbuild он в разы быстрее вебпака и при этом имеет вебпак совместимосте апи, так что вы вполне безболезненно сможете переехать и получить ощутимый буст в билде. Еще смутил момент обмена данными через шину, у вас же есть шаред стейт, зачем шина, или в шине все-таки только события? Паттерн паблишер-сабскрибер как раз плох тем, что в нем не ограниченное количество состояний. Такие кейсы когда ивент появился раньше слушателя, или слушать услышал уже не актуальный ивент и т.п. усложняют обмен данными. Раскройте тему с данными подробнее, пожалуйста.
Спасибо за оценку, давайте по порядку.
1) NextJS в нашем случае использует webpack, поэтому и для виджетов взяли webpack, чтобы можно было шэрить элементы конфига. Проблем со скоростью сборки тоже не заметно и не хочется иметь два разных сборщика на проекте. Посмотрел, появился плагин Rspack для NextJS, но пока стадия experimental. Будем следить, спасибо за наводку.
2) Shared state хранит в себе только кеш данных с бекенда. Никто другой туда данные не записывает, что обеспечивает их целостность.
3) Шина данных используется только для событий. Данные, которые передаются в событиях могут попадать в state веб-приложение (React Context), но не в shared state. Событие может вызвать refresh кого-то запроса на бекенд, данные обновятся и только тогда попадут в shared-state.
4) Кейсов с потерей событий, если нет слушателя не возникает. Так как слушатели инициализируются в React-компоненте, который импортирует виджет. Есть глобальные слушатели для служебных каналов, но они инициализируются на старте приложения.
Надеюсь ответил на вопросы
Какой смысл был в микрофронтах относительно монолита? Почему до конца не разобрались с module federation, он на том же Вите хорошо работает? С ssr ещё меньше проблем, так как на клиент статика отдается
1) Я в статье написал о причинах, когда 3 монолита с зоопарком стека, задачу можно делать по 3 раза. Это очень расточительно и долго.
2) С Module Federation разобрались, был прототип, была оценка трудозатрат и roadmap. Vite нам вообще никак не подходит с Next.js. Как раз когда мы ковырялись с MF команда Next объявила, что она не будет заниматься поддержкой MF. Open source плагины имели слишком большое количество багов. На момент был плагин MF для Next с поддержкой SSR, но в новой версии он ломался. Если коротко, то для перехода на MF нужно было все целиком переделать и непонятно какие плюсы от этого получить.
У нас такой зоопарк, что даже разные версии реакта через module federation протягиваем. Но тут Вити не хватает, классический вебпак нужен
У нас в проекте NextJS. Подключаем как модули так и MF. В модулях прокидываем in/out порты по принципу чистой архитектуры. Все красиво, но трудозатратно (модули UI, Core влияют на всех) и высокий порог входа для разрабов из других команд. MF делается быстрее, и важный плюс - свой независимый релизный процесс. Но за ними нужно очень внимательно следить. Если что-то в MF падает, вопросы все равно задают хосту.
Build-time микрофронтенды, или делай проще