Comments 16
Как у вас микрофронтенды общаются друг с другом? Потому что на бумаге оно все хорошо, что логика независимая, но по факту она становится зависимой часто! Берем примеры!
У вас есть какой-нибудь баланс, который нужно обновить после того, как что-то произошло на странице в другом МФ.
У вас есть куча лендингов, которые классно выносятся в МФ. А потом приходит бизнес и говорит хотим интерактивную форму на одном лендинге такую же, как в каком-нибудь МФе, чтобы пользователь мог прям тут на лендинге что-то поискать. Что будем с этим делать?
В идеале микрофронты не должны общаться друг с другом, иначе это нарушает основные преимущества микрофронтенд архитектуры. Если хотите данные показать на разных микрофронтах, обращайтесь к их бекендам, либо они могут к одному обращаться, это не нарушает принципы микрофронтендов.
Либо использовать события для взаимодействия между микрофронтендами чтобы подать сигнал что данные изменились и пора их обновить.
Отвечая на второй вопрос, я уже упомянул, что мы можем общие переиспользуемые вещи выносить на уровень libs, эта концепция взята из nx.dev, можно почитать здесь.
Иначе если у вас будут микрофронты иметь прямую связь между друг другом, то если упадет один микрофронтенд, то может отвалиться часть функционала в другом, что не очень хорошо.
Верно и для бекенда. Микросервисы как и их микрофонты строятся независимыми. Если декомпозировать на независимые компоненты не получается, значит стоит оставить монолит как есть и перестать беспокоиться. Как верно заметили, сообщения что ходят по бекенда через них же и попадают во фронт.
Есть вопрос. Как проще всего сделать динамические урлы ресурсов? Чтобы через форму в базовом приложении добавлять другие приложения с рендером их в див?
Разобрались с проблемой, оказывается в package.json поле name повторялось у двух микрофронтов, поэтому webpack думал что мы один и тот же проект пытаемся загрузить и он брал из кэша.
Вообще, замечал, что когда строят микросервисную архитектуру оставляют фронтенд монолитным что несколько нарушает ее. В книжках по МСА тоже обходят эту скользкую тему стороной.
Автор, спасибо за статью. Пишите ещё, хорошо бы и для новичков тоже, и бекендеров которые умеют в МСА но на беке. Микрофронты есть куда развивать. Один Module Federation, хрупкий и прожорливый, так себе вариант.
Я считаю, что разделять фронт на части, имеет смысл только если мы хотим разрабатывать эти части разными людьми, или в разном темпе. Это подразумевает, что в разных частях могут получаться разные версии всех зависимостей. Например, какую-нибудь админку заморозили - и там прошлогодний реакт. Также, скорее всего захочется разойтись по отдельным репозиториям. Вероятно - иметь возможность вообще сменить фреймворк.
То, что предлагают nx и webpack - это просто геморройный способ разложить тот же самый монолит по папочкам. Оно не дает никаких приемуществ над монолитным фронтом, порезанным на чанки.
если у вас разные будут версии библиотек в микрофронтах, то могут быть проблемы с shared модулями, мы их указываем, чтобы в целом у нас единая система была. На nx.dev том же пишут, что нужно стараться использовать одну экосистему, не нужно angular, vue и react мешать. Это же и справедливо к актуальности библиотек используемых микрофронтами.
А что касается монорепозитория, есть аналоги решения приведенного в статье - lerna и т.д.
Плюсы использования монорепозитория можете найти в интернете. И он никак не связан с монолитом, за исключение того, что у нас в монорепе общие зависимости для всех микрофронтов. Там очень много плюсов. Но бывают случае, когда бизнес приходит и говорит, что наши микрофронты делают разные компании под nda и доступа у них к коду друг друга нет. Но тогда придется согласовывать этапы встраивания микрофронтов между друг другом, возможно согласовывать стек и версии библиотек.
Да и если в интренете посмотреть, то компании чаще выбирают монорепозитории, чем микрорепозитории. Просто потому что это предсказуемо и управляемо. Меньше потенциальных багов.
А я и не говорю, что монорепы плохо. Я говорю что если все части юзают одинаковые версии зависимостей и лежат в одной репе - то можно их просто разложить на под-папочки в /src. И получить тоже самое, что дают эти все module federation и nx.
"разложить на под-папочки" можно по разному: монолит, многослойная, fsd, ddd, модульная.
Не нужно путать монорепу с микрофронтами, монорепа это про другое. Суть микрофронтов в том, что они размещаются на разных адресах и общение между ними только по сети.
nx.dev это ведь инструмент для работы c монорепозиторием, а микрофронты это webpack module federation.
Не буду спорить что такое «микрофронты», т.к. это придется опускаться на уровень Дяди Боба, и остальной псевдо-науки.
Часто есть смысл в том, чтобы разделить веб-сайт на части так, чтобы можно было их независимо разрабатывать и отдельно деплоить. Часто (но не всегда) удобно разделение репозиториев. И, по определению, требуется чтобы можно было независимо обновлять зависимости. Иначе отдельно деплоить и разрабатывать - не выйдет. А вот эти все вебпаки и rx - не очень про это. Т.е. задачу разрабатывать и деплоить независимо - они не решают.
Мы вот пакуем микрофронты в es6-модули, изолируем через shadow dom, билдим из разных реп, и деплоим независимо. Да, есть оверхед от нескольких реактов, но это осознанный минус, без этого задача разделить разработку - не решается.
Если зависимости есть возможность обновлять одновременно везде - то я не вижу никакого смысла в каких-либо выкрутасах, т.к. стандартный набор инструментов - типа того же vite - умеет все тоже самое, что и этот весь модный тулинг для «микрофронтов».
И мне решительно непонятно зачем нужна module federation, когда есть стандартные es6-модули.
module federation не имеет тех минусов, что есть у shadow dom. И опять вы приводите не корректное сравнение. Они решают разного рода задачи.
А чем не нравится shadow dom?
Кстати, у нас тоже микрофронты на модулях es6. Невероятно удобно.
Shadow dom это больше про изоляцию компонентов.
Почитай про Web Components, shadow dom является его частью.
Я задал вопрос не о том, что такое Shadow dom, а чем он не понравился.
Возможно, вы не в курсе, что Shadow dom работает в первую очередь с HTML-элементами. Берете блочный элемент, открываете его тень и пишите туда контент. И не нужно использовать веб-компонент.
Можете внимательно почитать довольно годную статью о том, что такое Shadow dom
какой вопрос, таков ответ. Зачем тогда спрашиваете про shadow dom, если знаете ответ. Если говорить про особенности shadow dom, как я говорил, он изолирует каждый компонент.
Не получится переиспользовать глобальные стили.
Есть проблемы с тестированием.
Проблемы с SEO.
Дополнительные затраты на хранение изолированного состояния.
Проблема с дебагингом кода.
es6 модули решают абсолютно ту же задачу, что module federation. Совершенно стандартным, поддерживаемым всеми браузерами, и доступным для любого бандлера, и даже для vanilla JS способом.
Я тут нагуглил, что это теперь пиарят под названием "Native Federation". Да, они придумали модное название для "просто возьмите стандартные ES6-модули"!
А Shadow DOM в моём случае - дополнительно изолирует стили, чтобы один микрофронтенд не побил стили другого на одной странице.
Правильные ли у вас микрофронты?