Как стать автором
Обновить

Комментарии 20

А чем это лучше продуманного разделения приложения на модули? Или это для тех, кто не смог?

Имеешь в виду без использования module federation? А как подключать модули друг к другу тогда?

Эммм, package.json dependencies + import?

Нуу, считай уже это не микрофронт) С таким подходом не удобно работать с lazy loading, библиотеки придется импортить в каждый конкретный модуль, а с помощью MF их можно передать дочернему приложению, плюс версионирование вроде как нельзя автоматическое настроить: когда залил новую версию модуля, нужно в использующем приложении либо руками поменять, либо как-то скриптом дернуть

Микрофронт != MF.
Там делов сделать сборку на том же Rollup - вообще мизер. Не вижу проблем вообще.

Согласен, но я описал проблемы, с которыми можно столкнуться. Я сам так делал раньше, но перешел на MF, потому что он действительно слишком сильно жизнь упрощает

Я не работаю с module federation. А с чудовищем WebPack завязал лет 10 назад. Отсюда непонимание.

Вот сделали мы хостовое и дочерние приложения. Они должны собираться одновременно или порознь? Они должны как-то видеть настройки сборки друг друга?

Тут я вижу два варианта:

  1. Приложения собираются независимо. Значит хостовое приложение - просто CDN, который хостит разделяемые модули. Но это легко реализуется без module federation.

  2. Приложения собираются вместе и хостовое приложение делает tree-shaking, например, и хостит только те части кода (чанки), которые реально используется приложениями. Но, во-первых, это опять-же реализуется без использования module federation. Достаточно всю сборку делегировать в хостовое приложение. А во-вторых, как быть с развёртыванием? Ведь если обновить дочернее приложение, но не обновить хостовое (или наоборот), то приложение просто сломается. То есть обновлять их нужно одновременно, что "не очень", мягко говоря.

Я чего-то недопонимаю, наверное.

Поддержу вопрос и добавлю еще один, так как я тоже не понимаю преимуществ MF.

Вот у нас Ангуляр и мы собираемся разбить большое приложение на парочку поменьше. Хранить их будем в разных репах, каждая со своим пайплайном.

Как подключать лучше репы друг к другу, если нужно использовать не только бандл, но и код? Прописывать в `package.json` ссылки чтобы `node_modules` вытягивались? Или делать в гите вложенные репы или submodules?

В данном случае лучше монорепозиторий, а не две отдельные репы.

Ещё можно публиковать собранные пакеты в NPM (приватно). Поддерживается GitHub. Или можно поднять копоративный Verdaccio. Но монорепозиторий проще.

В моём случае я тоже эти два варианта предлагал, но заказчики хотят mf и разные репы. Вот я и хотел узнать лучше практики. Набросок у меня есть, но mf — немного лишний, как вы выше заметили.

Вот у нашей команды и стояла цель: разбить большое приложение на модули. И мы успешно перешли на MF. Тем более module federation есть не только в вебпак, энтузиасты для роллапа его сделали

Обновлять одновременно не надо. Обновил дочернее, хвостовое это сразу подтянуло и ничего не сломалось.

Все это можно сделать и без MF, конечно, но MF предоставляет удобные инструменты, которые позволяют не думать о том, как развернуть, как управлять либами и так далее

То есть сборка чанков происходит динамически, во время выполнения? В статье, к сожалению, сам механизм не описан.

Не совсем так, сборка чанков осуществляется, когда мы кладем наше приложение на файловую систему сервера. А с помощью файлика remoteEntry мы уже забираем нужные нам чанки.

И мы сами можем рулить в какой момент какой модуль брать

Мой косяк, что не описал подробно механизм в статье. Либо здесь же исправлю, либо сделаю отдельную статью, так как и так эта подучилась большой, хотя я не супер глубоко уходил

Оставлю небольшой комментарий от себя. Когда я готовил статью, у меня не было цели рассказать про разные способы и показать, чем же MF лучше или хуже. Я хотел рассказать про собственное использование и с чем мы столкнулись.

Однако судя по комментам, стоило привести сравнение, возможно сделаю это в отдельной статье

Непонятно зачем они изобрели еще один формат модулей. Тоже самое делал и require.js, а сейчас - es6-модули, или systemjs.

requirejs не все может. Если нужна поддержка es6 или разные форматы модулей в одном проекте, то es6-модули и systemjs соответственно

Я к тому, что такого же эффекта можно было добиться, просто компилируя исходники в один/несколько es6/system.js модулей. Из того же вебпака. Был бы тот же набор фичей, но без магии, и работающий со всем что хочешь.

Мы именно так микрофронты и делаем, без всяких module federation.

Или я не вижу каких-то прям фичей, которые module federation дает сверх обычных модулей?

MF просто помогает проще все контролировать и управлять этим

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации