Женя, огромное спасибо за статью! Я хоть и фронтендер, но все понял.
Кстати, когда мы перейдем на версию яндекс.карт 3.0, так просто в космос улетим по производительности. Плюс будет очень удобно добавлять кастомные контролы прямо на один уровень с картой!
Административные методы (раскидывание зон\задач между командами) не дешевле и не надёжние ли будут чем организация и поддержка "микрофронтендов" на долгосроке?
Может быть и дешевле в моменте, но точно не надежнее. А если это кроссвендорная история и сегодня команда одна, а завтра — другая? Хорошая документация и грамотно разленная функциональность по приложениям думаю будет лучше в поддержке в долгосрочной перспективе.
Ну как как.. общением.. собрал лидов команд - вы делайте это, а вы - вот это, и не мешайте друг-другу. Если появляется пересекающиеся проблемы - опять собираемся и проговариваем как будем делать. Ну да, интровертам нужно выходить из зоны комфорта чаще))
Можно также собирать ПМов команд, какая разница?
зато меньше абстракций\кода - выше надёжность.. разве не так?
Грамотные абстракции как раз пишут для повышения надежности, а не для понижения. И самое главное когда код разделен по функциональности, то он лучше обособлен и «юнитизирован» получается. Это повышает надежность как раз. А в большом приложении велик соблазн этим пренебречь.
По ощущениям - единственный православно правильный способ. Делали так ещё пять лет назад - но тогда не было терминов "микрофронтенды"..))
Ну только пользовательский опыт другой совсем, всеж-таки это далеко не бесшовно..
Мы сделали на текущем проекте вариант с build-time интеграцией на npm-пакетах. Только есть нюанс, у нас у каждого приложения есть еще stand-alone режим, получается мы поддерживаем две сборки каждого прила — это потенциальное место для багов и нужно быть осторожным.
Вся «общая логика» у нас в одном большом npm-пакете и теперь я понимаю, что если бы его разделить на несколько отдельных (отдельно ui-компоненты, отдельно модуль авторизации кастомны, отдельно http-модуль-обертка над axios и тд), то было бы еще проще в поддержке и прозрачнее все. Эти пакеты бы все равно одна команда поддерживала, но в контексте было бы проще быть.
Из минусов я бы отметил конечно то, что очень много нужно с вебпаком делать, чтобы в итоге в бандле не было дублей.
А еще у нас деплой в s3 бакеты и веб-сервер настроен так, что все чанки он ищет в одном месте, а у нас они в разных лежат, потому что отдельные билды. Поэтому с деплоем тоже пришлось поколдовать..
Короче говоря подходы все достаточно молодые и нормальных «коробочных» решений пока и нет толком, что в общем-то, похоже нормально.
Женя, огромное спасибо за статью! Я хоть и фронтендер, но все понял.
Кстати, когда мы перейдем на версию яндекс.карт 3.0, так просто в космос улетим по производительности. Плюс будет очень удобно добавлять кастомные контролы прямо на один уровень с картой!
Может быть и дешевле в моменте, но точно не надежнее. А если это кроссвендорная история и сегодня команда одна, а завтра — другая? Хорошая документация и грамотно разленная функциональность по приложениям думаю будет лучше в поддержке в долгосрочной перспективе.
Можно также собирать ПМов команд, какая разница?
Грамотные абстракции как раз пишут для повышения надежности, а не для понижения. И самое главное когда код разделен по функциональности, то он лучше обособлен и «юнитизирован» получается. Это повышает надежность как раз. А в большом приложении велик соблазн этим пренебречь.
Ну только пользовательский опыт другой совсем, всеж-таки это далеко не бесшовно..
Мы сделали на текущем проекте вариант с build-time интеграцией на npm-пакетах. Только есть нюанс, у нас у каждого приложения есть еще stand-alone режим, получается мы поддерживаем две сборки каждого прила — это потенциальное место для багов и нужно быть осторожным.
Вся «общая логика» у нас в одном большом npm-пакете и теперь я понимаю, что если бы его разделить на несколько отдельных (отдельно ui-компоненты, отдельно модуль авторизации кастомны, отдельно http-модуль-обертка над axios и тд), то было бы еще проще в поддержке и прозрачнее все. Эти пакеты бы все равно одна команда поддерживала, но в контексте было бы проще быть.
Из минусов я бы отметил конечно то, что очень много нужно с вебпаком делать, чтобы в итоге в бандле не было дублей.
А еще у нас деплой в s3 бакеты и веб-сервер настроен так, что все чанки он ищет в одном месте, а у нас они в разных лежат, потому что отдельные билды. Поэтому с деплоем тоже пришлось поколдовать..
Короче говоря подходы все достаточно молодые и нормальных «коробочных» решений пока и нет толком, что в общем-то, похоже нормально.
Классная статья, жизненная. "Опыт не бывает отрицательным", такое резюме.
Спасибо ivanvorn! Приятно.
Надо будет только дескрипшн обновить в твиттере, сайтами на WordPress уже давно не занимался. Все больше как-то приложениями на JavaScript.
Но хочу обратить внимание, что к нему через хуки можно и Webpack накрутить.