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