Интересно как соотносятся понятия 'микрофронтенд' и 'микросервис'? Если микросервис - ето микрофронтенд + сервер + ДБ, тогда наверное для каждого такого микросервиса, которьій подключается на фронтенде через Module Federation, нужно отдельньій СІ/CD делать и держать в отдельном репозитории.
Спасибо за доклад. Тоже используем Webpack Module Federation. Но еще с некоторыми собственными архитектурными доработками. Например: Приложение собирается по json-конфигу, в котором прописаны какие модули загружать и куда подключать (как использовать) те. есть возможность конфигурировать приложение перед его поставкой пользователю. А вот с шарингом контекстов что-то не получилось пока.
@@Sultanbayev Действительно, кому нужны эти типы? 😄 Жили ведь без них 15 лет и норм. Можно еще и модули выбросить, тоже вещь бесполезная и писать скрипты, как в старые добрые времена.
Там было в докладе, что s3 на самом деле проприетарный и имеет урезанный функционал и просто нет возможности в паблик выкладывать бандлы и пришлось делать такой work around. Если есть возможность сразу использовать AWS, получиться намного проще.
6:00 - описание зачем это нужно - много сайтов, много комманд, сквозные интеграции. В общем когда количество разработчиков под 200 и есть независимые приложения с разделяемым функционалом это спасение
@@sergeys4732 да я послушал сколько телодвижений и проблем надо решить, чтобы оно просто заработало, и где-то явно разрабы свернули не туда. Было html, css, js, а теперь полтора часа костылей только в теории.
Thanks for sharing your knowledge! Can you share the code from this video? Or any code related to Webpack 5 module federation with prod build?
Интересно как соотносятся понятия 'микрофронтенд' и 'микросервис'? Если микросервис - ето микрофронтенд + сервер + ДБ, тогда наверное для каждого такого микросервиса, которьій подключается на фронтенде через Module Federation, нужно отдельньій СІ/CD делать и держать в отдельном репозитории.
Спасибо за доклад. Тоже используем Webpack Module Federation. Но еще с некоторыми собственными архитектурными доработками. Например: Приложение собирается по json-конфигу, в котором прописаны какие модули загружать и куда подключать (как использовать) те. есть возможность конфигурировать приложение перед его поставкой пользователю. А вот с шарингом контекстов что-то не получилось пока.
Норм преза, но зачем давай название `watch` ремоут-приложению? Усложняет восприятие.
А по типам что? Как во время разработки подтягивать ts типы из дочернего микрофронта?
а в микросервисах на бэке что-то похожее делают? зачем тянуть ts типы?
@@Sultanbayev Действительно, кому нужны эти типы? 😄 Жили ведь без них 15 лет и норм. Можно еще и модули выбросить, тоже вещь бесполезная и писать скрипты, как в старые добрые времена.
Я не понимаю, в чем сложность пошериться кодом?
51:27
столько возни чтобы в s3 publick bucket не выкладывать бандлы? Тыж сеньер авс помидор... зачем оно все?
а все понятно, они айпишники в конфиги кубера харкодят, вопросов не имею, 30 минут выкинуто
Там было в докладе, что s3 на самом деле проприетарный и имеет урезанный функционал и просто нет возможности в паблик выкладывать бандлы и пришлось делать такой work around. Если есть возможность сразу использовать AWS, получиться намного проще.
41:21
Зачем это все? Одна небольшая команда фронтов
6:00 - описание зачем это нужно - много сайтов, много комманд, сквозные интеграции. В общем когда количество разработчиков под 200 и есть независимые приложения с разделяемым функционалом это спасение
Компуктер рулит)) 😂😂
Это просто караул. Реально гемор того стоил?
на самом деле нет ни какого гемороя
@@sergeys4732 да я послушал сколько телодвижений и проблем надо решить, чтобы оно просто заработало, и где-то явно разрабы свернули не туда. Было html, css, js, а теперь полтора часа костылей только в теории.
@@iGotton Масштабировать зато легко.