Микрофронтенды и виджеты в 2021-м. Доклад Яндекса

[fransua]

Спасибо за хорошую статью, приятно было читать!
Скажите, а логику создания iframe/Realm и загрузки основного скрипта получилось выделить в универсальную фабрику виджетов?
И второй вопрос, насчет производительности, iframe это все-таки новый DOM, как сильно влияет на инициализацию страницы?

[MAD_GooZe]

да, это делается достаточно просто — можно написать функцию, которая создает фрейм и загружает в него необходимый скрипт
именно iframe заметных замедлений не дает

[AndreyMyagkov]

Что делаете, если нужно менять дизайн виджета в зависимости от размера контейнера куда вставлен виджет, при условии что виджет вставлен не в iframe (например, если контейнер большей — выводим информацию в 2 колонки, а если маленький — то в одну колонку)?

[MAD_GooZe]

тут поможет ResizeObserver — он позволяет отслеживать изменения размера контейнера

[yakimchuk-ry]

Извините, всю статью не прочитал, длинная, но труда вложено много, плюсую.

MF – У нас есть возможность разделения фронта на почти независимые виджеты, которые могут работать со своим стеком, и жить почти независимой жизнью, но на самом деле:

1. Все они вертятся в одном документе, если не использовать фрейм как песочницу (что сделать нельзя, потому что это очень медленно, и более 50 фреймов на странице держать сложно), т.е. либо мы делаем зоопарк из технологий на фронте (так делать крайне не рекомендую), либо формально они являются просто компонентами, которые разрабатываются независимыми командами.

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

Так что тогда такое MF?
Просто новое модное слово?

Наверное, я что-то не понимаю. Подскажите реальный профит MF over разделение ответственности между командами при разработке приложения, и в чем вообще разница?

[MAD_GooZe]

я постарался в начале доклада (до «Как технически реализовать микрофронтенды/виджеты?») как раз ответить на эти вопросы)
мне кажется, что в кейсе, о которым вы говорите, MF будут иметь реальный профит при разделении на фуллстек-команды (у виджетов будет свой отдельный бэкенд)

[Mike-M]

В Яндексе когда-то давно был проект Яндекс.Виджеты: можно было из библиотеки виджетов собрать себе персонализированную главную страничку Яндекса.

И это было чертовски удобно! Кому и почему пришла в голову идея избавиться от виджетов?

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

Но это все лирика. Поговорим о том, как технически реализовать микрофронтенды

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

Складывается впечатление, что Яндекс — это некий полигон, на котором «олимпиадники» имеют возможность прокачивать свои скиллы, да еще и деньги за это получать. А как такое скажется на юзерах — «это лирика».

P.S. Скоро налетят сотрудники и фанаты Яндекса и начнут активно минусовать. Причем, как обычно, без комментариев со своей стороны.

[Jery]

Не уловил как шарятся зависимости между виджетами? Если например 2 разных виджета используют реакт, то каждый из них загрузит свой?

[MAD_GooZe]

в общем случае да (если он вшит в бандл)
но если реакт вынесен в отдельный кешируемый бандл, то браузер достанет его из кеша
либо виджет может использовать window.React и из родительского window и вообще ничего не грузить

[maslyaev]

Не, ну правда... Хватит нам, бэкендщикам, одним страдать от того бардака, неоптимальности и безответственности, которые микросервисная архитектура принесла в нашу жизнь. Пусть фронтендщики тоже походят по этим граблям.

[zim32]

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