Comments 21
Вы начинаете статью с тезиса, что не используете библиотеки, фреймворки и прочие jquery. Мол, достаточно чистого js из коробки.
И тут же подцепляете тонну всего.
Ну, или я неправильно понял.
Ведь все необходимое для разработки и работы Микрофронтендов уже встроено во все современные браузеры.
import ReactDOM from "react-dom";И вот тоже как-то не понял...
Тоже этот момент смутил. Полагаю, в той части речь идёт о реализации интерфейса микрофронта (два метода), а нативный код встраивания описан ниже в
const microElement = document.querySelectorИнтересно попробовать собрать таким образом три-четыре Vaadin проекта.
Автор, не делали ли вы автодискавери микрофронтов? Нативно это была бы бомба.
Имелось ввиду без фреймворком разработки микрофронтендов, типа Webpack Module Federation, Single-SPA, SystemJS и т.п..
Но на самом деле данный подход можно использовать и без реакта, и вообще каких либо библиотек, и даже инструментов сборки. Браузер нативными средствами подтянет все импорты доступные по http/s.
Но все же лучше использовать микробиблиотеки и делать оптимизирующую сборку для клиентов.
Для webpack и vite достаточно использовать магические комментарии, чтобы запретить парсинг и разрешение зависимостей:
import(
/* webpackIgnore */
url
)import(
// @vite-ignore
url
);При этом мы не прибегаем к eval/new Function, не нарушаем CSP и тп.
Наверное, с вендор локом на технологиях MF, SSPA и тп можно согласиться, но аргументы против ИМХО несостоятельные, например, в официальной документации MF есть пример с указанием версий пакетов по semver, откуда появилась проблема в "новых версиях, в которых есть ломающие изменения" не понятно.
Когда мы говорим про микрофронты, без шаринга зависимостей и без коммуникации между микрофронтами, мы в сухом остатке получаем кучу независимых приложений на одной странице, со всеми вытекающими, ничем не отличающимися от того, как мы десяток лет назад встраивали разные виджеты, даже через те же iframe.
Например ваш микрофронтенд может быть реализован на react 18 с новыми хуками, а основное приложение на react 15 где новых хуков нет. И таким образом вы не сможете пошарить единый реакт между микрофронтендом и хостовым приложением.
В описанном же мною подходе команда реализующая микрофронтенд независима от технологий хостового приложения. В т.ч. свободно обновляет версии используемых библиотек. Главное не использовать тяжелых зависимостей.
Вопрос коммуникации микрофронтендов тут не затрагивался. Но легко реализуется либо через пропсы микрофронтенда, как с обычными компонентами, либо через общий Event Bus.
Например, в наших микрофронтендах шапки, футера, формочек такой общий код, как фреймворк и библиотеки, были вынесены в отдельные чанки и переиспользовались несколькими микрофронтендами. Таким образом уменьшалось количество кода, подгружаемого вместе с микрофронтендами.
Так всё-таки, шарятся зависимости или нет? Если да, как версии разруливаете?
Можете приложить ссылку github на данную реализацию?
МТС пишет на Тильде?
И говорит что-то о минимализме и эффективности в выборе технологий для фронта?
Промазал. Del.
Т.е. правильно я понимаю, если все ваши МФ будут использовать React одной версии, то на странице сайта будет N бандлов React'a зашитых в МФ? Это же влияет на скорость загрузки и прочие метрики. А Module Federation как раз позволяет это оптимизировать, шаря одну и ту же версию.
Да, если у вас микрофронты используют все разные версии, то Module Federation тут не поможет. Но это частный случай. И лучше иметь возможность шэрить общие либы, чем не иметь, нет?
И да и нет. Нет - в том плане что мы не используем реакт для микрофронтенда. Вместо него мы используем его легковесную альтернативу Preact. React + React Dom весит 128 kb, Preact весит 3.5 kb. Т.е. в 36 легче. Есть где разгуляться. Да - в том плане что в каждой группе микрофронтендов свой экземпляр Preact. Получается что на странице 2-4 экземпляра Preact + Preact на хостовом приложении. Это все еще в 6 раз легче 1 пошаренного Реакта.
Шаринг в MF работает только до тех пор пока у вас небольшой проект. Далее у вашей команды начнутся конфликты на тему что один разработчик хочет новый реакт, а другой говорит что пока не может поддержать новую версию реакта.
В моем случае было 15 внешних партнерских ресурсов + тильда. Заставить кого либо использовать нужную версию Реакта - нереально. Заставить апгрейдить версии Реакта одновременно - нереально. Заставить кого либо использовать реакт вместо вуе - нереально. Заставить шарить реакт на вуе проекте - нереально. Заставить настраивать кого либо MF там где его нет - нереально. Затащить MF в тильду - нереально.
А такое решение на базе микробиблиотек + динамический импорт отлично справляется со всеми перечисленными проблемами.
Догадываюсь, у вас разрабы "хостового" приложения - белые люди, а разрабы микрофронтендов должны страдать. Надо подключить серьёзную зависимость - а не дадут, ищи что поменьше. Хочешь писать на нормальном привычном фреймворке - а вот фигушки тебе. Да, такой подход имеет право на жизнь (как и любой другой), но я бы к вам на ваши "микро" не пошёл.
А теперь представим ситуацию. Вы разработали микрофронтенд на ваших любимых технологиях. Допустим это Angular 9.10, jQuery 2.15 и Moment 2.14, сборка Webpack + MF. А теперь вам пришла задача: Вам нужно провести интеграцию вашего микрофронтенда с популярным продуктом другой компании. Популярный внешний продукт является хостовым приложением, вы в него встраиваете микрофронтенд. Хостовый продукт написан на React, заботиться о SEO и Клиентских метриках. Производительность для них крайне важный вопрос. А теперь вы приходите в этот продукт и говорите: А обеспечьте ка мне в зависимостях Angular, jQuery, Moment нужной мне версии, а еще у меня MF от Webpack, поэтому выкиньте свою сборку на Vite, а еще из-за моих тяжелых библиотек у вас Seo и Клиентские метрики просядут. Предугадайте последствия?
И понятное дело что вы уже не разрабатываете на Angular, jQuery и Moment. Но разработчики vue, svelte и тп. именно так воспринимают React + Redux и все остальные ваши любимые зависимости как вы сейчас восприняли Angular, jQuery и Moment.
Готовим микрофронтенды на чистом JS без фреймворков