Комментарии 30
А как решается проблема со стилями, что будет если в разных модулях окажутся стили для одинаковых классов?
Получение стилей как и остальной статики, разруливается через baseHref, так что мы исключили такую возможность. Модуль получит только тот набор стилей что запросил + глобальные стили из хоста
Не очень понял, что такое basehref? Для двух модулей на странице создадутся два элемента style в которых могут оказаться конфликты, например класс .content, который окажется в разных модулях в нескольких элементах, разве нет?
1) А микрофронтенд может использовать другой микрофронтенд? Или всех их разруливает (роутит) ядро?
2) Работает ли hot reload при разработке?
3) Работает ли SSR? И видит ли node.js что микрофронтенд обновился при hot reload
1. Да можно использовать, для этого внутри ремоута нужно определить роут и вызвать с помощью функции loadRemoteEntryModule().
2. При использовании nx-workspace автоматом перезагружается хост, но появилось это относительно недавно, до этого приходилось ручками обновлять страницу в браузере. В остальном hot работает как надо
3. Поддержка SSR заявлена, но не совсем отлично работает, поэтому данный момент пока держу за скобками и отложил в бэклог)
Спасибо за статью, как раз сейчас стоит задача перевести приложение с микрофронтами (angular-architects) на SSR. Отсюда просьба, дать какой-то совет или ссылку "что почитать", чтобы этот путь не был столь долог, опасен и не стал тупиковым) пожалуйста!
puppeteer + cache, в фоне кэш страниц обновляется, а на запрос странички отдается сразу готовый HTML из кэша, работает супер быстро и никаких переделок на фронте не требует, после загрузки бандла просто данные зафечатся по новой которые при загрузки отображаюся и пользователь увидит их самыми актуальными, а для поисков пофиг что они могут быть на 5-10 минут "устаревшие", на SEO это не влияет
Оу, спасибо, изучу и этот вариант!
Осторожнее с этим вариантом.
Запуск браузера на сервере для получения сгенерированного фронтом HTML — это куча накладных расходов, которых, как правило, можно избежать.
Нет. Это копейки. 1-2 экземпляра запущенных которые обновляют кэш и периодически перезапускаются дабы избежать возможных утечек памяти.
Альтернативы 3:
1) Нe использовать SSR.
2) Использовать классические схемы типо PHP + jQuery и т.п.
3) Превратить свой проект в говнокод и получить на ровном месте дополнительно связанные руки, ограничения, реальную нагрузку на сервер и использовать всяческие Next.js, Nuxt.js и прочую фигню.
Если я правильно понимаю, то для SSR приложения из 25 микрофоронтов нужно будет поднятые 25 приложений на ангуляре? Предложенный вариант можно использовать с кешем и только для отдачи ботам. Что думаете? Есть ответ на первый вопрос? спасибо.
Что вы имеете в виду под "25 поднятыми приложениями"?
25 приложений, которые слушают определенный для себя порт.
Обычный сайт - раздается как статика, SSR - слушает порт и отдает сформированный HTML и статику. И продолжая эту логическую цепочку, я предположил, что SSR в 25-ти микрофронтах - это 25 таких слушающий порт приложений. Или это совсем не так и запускаем только основное, а остальное билдим? На данный момент я вообще не понимаю как начать SSR на angular-architects
Запрос от браузера направляется только на один веб-сервер, и он-то и будет заниматься SSR. И рендерить, как и в браузерном случае, он будет в первую очередь приложение-оболочку (app shell), рендер микрофронтов является ответственностью этой самой оболочки.
То, что запрос отправляется один - понятно. Я именно про рендер микрофронтов. В дев режиме - это же запущенные приложения, а в проде собранные js файлы. При SSR как должен выглядеть рендер микрофоронтов? Нет ли случаем ссылки на мурзилку или что-то похожее?
Ну вот смотрите. Как происходит рендер в браузере? Сначала рендерится оболочка, которая загружает один или несколько микрофронтов и говорит им отрендериться.
Как должен происходить SSR? А так же, сначала рендерится оболочка, которая загружает один или несколько микрофронтов и говорит им отрендериться.
Где на этом этапе могут выплыть 25 слушающих сокет приложений?
Да хоть 125 и хоть на всём подряд, react, angular, vue, jquery, svelte и т.п.
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.org', {
waitUntil: 'networkidle0',
});
// Полностью отрендереный HTML на 125 микрофронтах с использованием любым библиотек и фреймворков
const bodyHTML = await page.evaluate(() => document.documentElement.outerHTML);
redis.set(pageUrl, bodyHTML);
await browser.close();
})();
Микрофронтенды решают много проблем, но и привносят достаточно новых.
Я так понимаю используется несколько ангуляр приложений. Не возникает проблема с zone.js?
Но помимо монолитного фронта обычно есть еще и монолитный бэк. А это значит, что будем распиливать и фронт, и бэк.
Ловко. Возьму на вооружение.
- Надо отрефакторить фронт.
- Значит и бэк будем, а то что это он!
Насколько понимаю, нельзя сделать шеллом реакт приложение, а вот ангуляр с его роутингом привязывать как микрофронт? То есть решение исключительно для ангуляр команд?
ПС почему Modul Federation? Вроде как Module Federation
Технически можно. Но если делать без ухищрений по генерации и загрузке разделяемых бандлов, то ангуляр будет входить в каждый из микрофронтов, что конфликтует с приставкой "микро".
Я спрашиваю потому что в полуоф репозитории такого семпла нет, видел только такой, без Ангуляра https://github.com/module-federation/module-federation-examples/tree/master/react-in-vue
Но класс если вы делали!
(Микро)фронтенды и микросервисы с помощью Webpack