Комментарии 20
А чем это лучше продуманного разделения приложения на модули? Или это для тех, кто не смог?
Имеешь в виду без использования module federation? А как подключать модули друг к другу тогда?
Эммм, package.json dependencies + import?
Нуу, считай уже это не микрофронт) С таким подходом не удобно работать с lazy loading, библиотеки придется импортить в каждый конкретный модуль, а с помощью MF их можно передать дочернему приложению, плюс версионирование вроде как нельзя автоматическое настроить: когда залил новую версию модуля, нужно в использующем приложении либо руками поменять, либо как-то скриптом дернуть
Я не работаю с module federation. А с чудовищем WebPack завязал лет 10 назад. Отсюда непонимание.
Вот сделали мы хостовое и дочерние приложения. Они должны собираться одновременно или порознь? Они должны как-то видеть настройки сборки друг друга?
Тут я вижу два варианта:
Приложения собираются независимо. Значит хостовое приложение - просто CDN, который хостит разделяемые модули. Но это легко реализуется без module federation.
Приложения собираются вместе и хостовое приложение делает tree-shaking, например, и хостит только те части кода (чанки), которые реально используется приложениями. Но, во-первых, это опять-же реализуется без использования module federation. Достаточно всю сборку делегировать в хостовое приложение. А во-вторых, как быть с развёртыванием? Ведь если обновить дочернее приложение, но не обновить хостовое (или наоборот), то приложение просто сломается. То есть обновлять их нужно одновременно, что "не очень", мягко говоря.
Я чего-то недопонимаю, наверное.
Вот у нас Ангуляр и мы собираемся разбить большое приложение на парочку поменьше. Хранить их будем в разных репах, каждая со своим пайплайном.
Как подключать лучше репы друг к другу, если нужно использовать не только бандл, но и код? Прописывать в `package.json` ссылки чтобы `node_modules` вытягивались? Или делать в гите вложенные репы или submodules?
Вот тут предлагают публиковать type definitions рядом с кодом, через MF: https://spin.atomicobject.com/2022/07/19/typescript-federated-modules/
Обновлять одновременно не надо. Обновил дочернее, хвостовое это сразу подтянуло и ничего не сломалось.
Все это можно сделать и без MF, конечно, но MF предоставляет удобные инструменты, которые позволяют не думать о том, как развернуть, как управлять либами и так далее
То есть сборка чанков происходит динамически, во время выполнения? В статье, к сожалению, сам механизм не описан.
Не совсем так, сборка чанков осуществляется, когда мы кладем наше приложение на файловую систему сервера. А с помощью файлика remoteEntry мы уже забираем нужные нам чанки.
И мы сами можем рулить в какой момент какой модуль брать
Мой косяк, что не описал подробно механизм в статье. Либо здесь же исправлю, либо сделаю отдельную статью, так как и так эта подучилась большой, хотя я не супер глубоко уходил
Оставлю небольшой комментарий от себя. Когда я готовил статью, у меня не было цели рассказать про разные способы и показать, чем же MF лучше или хуже. Я хотел рассказать про собственное использование и с чем мы столкнулись.
Однако судя по комментам, стоило привести сравнение, возможно сделаю это в отдельной статье
Непонятно зачем они изобрели еще один формат модулей. Тоже самое делал и require.js, а сейчас - es6-модули, или systemjs.
requirejs не все может. Если нужна поддержка es6 или разные форматы модулей в одном проекте, то es6-модули и systemjs соответственно
Я к тому, что такого же эффекта можно было добиться, просто компилируя исходники в один/несколько es6/system.js модулей. Из того же вебпака. Был бы тот же набор фичей, но без магии, и работающий со всем что хочешь.
Мы именно так микрофронты и делаем, без всяких module federation.
Или я не вижу каких-то прям фичей, которые module federation дает сверх обычных модулей?
Module Federation — что скрывается под кажущейся простотой