Comments 18
формировались новые команды, но мы не всегда могли аккуратно разграничить зоны ответственности
Очень интересно, что именно не получалось? Не слушались?))
если у вас несколько команд и большое приложение, микрофронтенды – крутое решение
Неужели настолько "круче", чем обычный административный способ. Собрать лидов команд - сказать "Вася, ты со своими ребятами пилите шапку. А ты Петя со своими - будете делать сайдбар. Ваня, ты со своими джунами - полите ui-kit. А мы будем главную. Каждая команда работает в своей ветке. Если будут пересекающиеся вопросы\фичи - организовываем созвон и обсуждаем".
Удобная локальная разработка: работаешь в рамках одного микрофронтенда
И также для локальной разработки очень часто нужно не рамки одного микрофронтенда, а весь контекст проекта целиком. Иначе ж получится - "ничего не знаю - у меня всё работает")
Если каждая команда условно хочет пилить как ей вздумается на чём угодно, то любой "микрофронтенд" может крайне легко сломать весь сайт. А огромная куча самых разных зависимостей, ещё и разных версий просто приведёт к тяжёлому зоопарку. Совершенно согласен, уж лучше бы в таких условиях перешли на iframe, и не пытались на соплях и скотче сделать нормальный продукт. Можно договориться и делать продукт в плотной коллаборации, на одних инструментах, это не мешает развиваться, если делать по уму.
У нас вот есть крупный монолит на vue2 + vuetify2 + еще куча разных библиотек, которые давно уже не поддерживаются и vue2 only. Сделать сейчас миграцию на vue3 - это боль. Уже была пара попыток, но пока никак. Слишком много правок и изменений, на которые требуется слишком много времени, а бизнесу ждать некогда, бизнесу нужны новые фичи (традиционно еще вчера).
Если бы у нас был не монолит, а микрофронтэнды, то новые фичи пилились бы уже на vue3 с использованием актуальных библиотек, а старые фичи потихоньку переписали в относительно свободное время.
Но минусов у микрофронтэндов тоже достаточно, да и вариантов как распилить монолит не переписывая всё я пока тоже не вижу.
Вы так говорите, как будто переход на Vue3 это самоцель :) Потребитель-то что получит? В случае зоопарка из Vue2+Vue3+React+Angular+бог знает что ещё на одной страницы, радости будет маловато. И что толку, если кусок будет на блистающем свежем Vue3, а остальное нет?
Всё же, для пользователя это единый продукт, один сайт, цельный, и работать он должен единообразно везде, не тормозить, не глючить, и не грузиться вечность. Если у него будет тупить один из экранов, он вряд ли подумает, а ну это команда Васи, в остальном-то всё ок :) Нет, пользователь будет испытывать гнев ко всему решению в целом, и достанется всем.
И я ещё больше скажу. Ладно там поддержка и развитие. Ещё есть ИБ. И требования к безопасности с каждым днём растут. Как же будет рад отдел ИБ, исследуя это лоскутное одеяло из зависимостей разных версий в одной поделке!
Разработчики не должны думать только о себе. Иначе это не инженеры. А инженер на то и инженер, он должен придумать как решить проблему в условиях существующих ограничений.
В нашем случае цель - избавиться от неподдерживаемых пакетов, на которые ругается npm audit. Ну или хотя бы уменьшить их количество до минимального значения.
Так что нет, цели перейти на vue3 как таковой нет, но способов решения существующей проблемы возможно несколько, нужно только выбрать по какому именно пути пойти.
Конечно, ты прав
Если бездумно переписывать с одного фреймворка на другой, ничего для бизнеса ты не сделаешь
Конкретно у нас была проблема, что код устарел и имел ограничения, которые не позволяли масштабироваться продукту и быстро решать его проблемы
Переходя на микрофронты мы не просто меняем один фреймворк на другой, мы:
1) Рефакторим приложение и находим уязвимые места (не останавливая производственный цикл)
2) Даем возможность быстро создавать новые команды и микрофронты, не ломаю текущую функциональность
3) Само производство ускоряется, так как релизы становятся независимыми и быстрыми
Все 3 пункта положительно влияют как на разработчиков, так и на конечных пользователей
Всё же качество сильно просядет, так как ничего не бывает бесплатным. Загружать на лету, на одной странице разные модули с разных ресурсов -- на этом же построен весь клиентский веб! :)
Но, одно дело, если это полностью самодостаточные и независимые виджеты, например, плашка с погодой, калькулятор, какой-то отчётик на панельке. Другое, когда это изначально цельное приложение, имеющее сложное состояние, когда все компоненты имеют высокую степень связности, и это прослеживается в пользовательских сценариях.
Когда, например, не теряя контекст при оформлении заказа, будет учитываться сразу доставка, акционка, бонусная программа, инвайты, история покупок, другие продуктовые истории из клиентского профиля. Когда это не будут просто отдельные экраны, со своим миром, а цельный, единый и непрерывный мир.
Как юзер, я имел опыт использования подобных микрофронтендов, и в банковских продуктах, и в продуктах страхования. Вам не доводилось на одном и том же сайте, вводить одну и ту же информацию дважды, трижды? Как будто с вами разговаривает приложение-склеротик. А при переходе буквально по одной кнопке, как будто резко сбрасывают память, половина не грузится, или вообще грузится что-то не то.
Описанный п.3 в вашем сценарии, это не про бизнес. Это про священный Т2М и удобство разработчиков, где пользователю отведено самое последнее место в ценности продукта.
Лично я вижу хорошее решение "микрофронтендов" в модульности и едином строгом фреймворке-хосте. С качественным применением паттернов. И здоровые цели, не такие "хочу свежий вью 3 и новые библы", а "хочу качественный, крепко сбитый, продукт, который работает и ведёт себя конгруэнтно на всём пользовательском пути".
Но, возможны и такие сценарии, как маркет-плейсы приложений, куда загоняют просто кучу разношёрстных самостоятельных приложений под одну крышу. Возможно там и правда нет никакой связи между функцией А и функцией Б, они вполне могли бы быть на отдельных доменах, просто с одним лейаутом. Без контекста сложно сказать конечно :)
Не хочу уходить в дискуссию, но как-будто вы сразу поставили клеймо "просто они захотели новые технологии" на нашем решении.
Мы же, все-таки, все это делали ради продукта. Для меня правильно выстроенная архитектура - хороший технический продукт, который не ломается и удобен пользователю.
Теперь по пунктам:
1) Приложения независимы, но они могут шарить данные между собой. Если вам нужно отобразить данные сразу в нескольких микрофронтах - вы можете это сделать (описывал в статье)
2) Как по мне быстрый деплой - это в первую очередь про пользователя. Когда вам нужно быстро откатить баг, гораздо приятнее это сделать за пару минут, чем ждать несколько часов. На разработчика вообще непонятно как это влияет, я наоборот могу пойти за это время кофе попить и чем дольше, тем лучше ?
3) Вы написали "Лично я вижу хорошее решение "микрофронтендов" в модульности и едином строгом фреймворке-хосте". Так у нас, можно сказать, так и сделано. Есть единый хост, модули и свои паттерны. Может вас смутило упоминание сразу и Angular, и Vue. Еще раз повторю - мы не гнались за новыми технологиями, мы выстраивали правильную масштабируемую архитектуру на старом проекте и попутно его переписывали на новые технологии, которые нам кажутся удобнее.
Ну тут уже какой-то негатив пошел)
Наши цели я озвучил в начале статьи - отрефакторить большое приложение, переписать его на новые технологии + разделить на независимые сервисы.
Наоборот, нашим подходом мы лечим наш продукт и легко его масштабируем
iframe имеют много ограничений, на это уже есть доклады, можно глянуть их
Интересные мысли)
Административный способ 100% работает, но работает в маленьких/средних компаниях (это чисто моя условные обозначения, приводить кол-во людей не буду ?)
Если компании уже большая ей очень важно, чтобы приложение было максимально стойким (теряют большие деньги все-таки). И если уже что-то отваливается, то пусть остальной функционал работает
Теперь привожу пример
Вася выкатил новую фичу, но тут, внезапно, отвалился раздел с заказами. Вася в шоке, ведь он трогал настройки склад, совсем другой раздел.
Ты можешь сказать "Как так, почему выкатили не рабочий функционал". Человеческий фактор никто не отменял, невозможно все учесть на 100% и провести регресс всего сайта для каждой фичи
Поэтому, чтобы минимизировать вот такие случаи, мы и делим наш код на отдельные сервисы
Продолжая ответ на вопрос:
1) "Если будут пересекающиеся вопросы\фичи - организовываем созвон и обсуждаем". Мы так и делаем, еще больше скажу - с микрофронтами это делать еще проще, так как у тебя расчерчены границы
2) "И также для локальной разработки очень часто нужно не рамки одного микрофронтенда" - ты можешь запускать как отдельный микрофронт, так и 2, так и все приложение целиком. Если я делаю кнопку в поддержке, мне раздел заказов (например) не нужен
Ваш подход сработает в чисто продуктовых кампания. У нас же, например, есть продукт, своего рода коробка и проект, который кастомизирует заказчик под свои нужды. Микрофронтэнды стали спасением, ибо теперь у нас одна версия продукта, а проекты уже ваяют свои расширения отдельно от нас. Раньше же продукт выдавался де факто как огромная либа и под каждого заказчика был свой релизный цикл с постоянными прокидываниями фич и багофикса. Экономия реально измеряется в тысячах человекодней на оперейшен саппорт.
а почему webpack module federation не использовали?
Если кратко - это чуть разные вещи для разных задач.
Single-spa помогает выстроить архитектуру из независимых приложений, которые могут быть написаны на разных технологиях. Позволяет удобно организовать роутинг между ними и управлять состояниями.
Module federation - больше про шаринг модулей одного фреймворка. Допустим у тебя большое приложение на Vue, но ты его хочешь раздробить и распределить по отдельным репам. После настройки MF ты сможешь это сделать и главное будешь подключать код из этих реп как обычные компоненты (звучит оч удобно и круто)
Вообще эти подходы можно даже комбинировать. Ты тащишь себе в проект single spa, выстраиваешь архитектуру, а module federation тебе позволяет шарить какой-то общий код.
НО
Чтобы использовать MF сразу для разных фреймворков, нужно заморочиться и писать свои доп обертки, чтобы дружить проекты между собой и там, на самом деле, вытекает много подводных камней. И тут возникает вопрос, а зачем тогда накручивать все это на MF, если есть готовый single-spa
Суммируя текст выше - наша задача "перейти на новый фреймворк и сделать независимые приложухи", и мы выбираем single-spa, тк именно на этом он и специализируется
Вы на полном серьёзе делаете шапку сайта отдельным микрофронтом со своей выкладкой, репозиторием, библиотеками ТП. Оно реально стоит того? Не представляю насколько низкий технический уровень должен быть чтобы выделять команду на разработку шапки сайта. А что потом произойдет с командой? Когда они осилят вёрстку лого, меню и возможно иконки профиля? Футер у вас тоже микрофронтенд? После прочтения, осталось ощущение, что у вас самоцель была попробовать хайповую тему.
Не не не, у нас нет распределения 1 команда - 1 микрофронт ?
В каждой команде есть по 3-4 микрофронта (а то и больше) со своей бизнес логикой. Есть общие фронты (шапка, навигация, роутер), в них могут вносить изменения любые разрабы, если это подразумевается в задаче. Например сделал новую страничку в своем сервисе - добавил ее в общую навигацию.
По поводу вынесения шапки в отдельный микрофронт - вещь холиварная. То что мы теряем в оптимизации, это да, но зато получаем проект с легко читаемым кодом (что для программиста оч важно), независимый и быстрый деплой (в реалиях больших компаний тоже ключевой фактор) + защиту от случайных багов (шапка будет жить даже если один из разделов отвалится)
Но выбирать, конечно, тебе)
А почему решили сменить фреймворк?
Просто любопытно почему остановили свой выбор на SystemJS? Почему не https://github.com/guybedford/es-module-shims например? Полифилит в том числе и importmap и позволяет нормально esm модули использовать в продакшене, без необходимости билдить AMD-модули. Плюс потенциально через некоторое время, когда importmap и ES Modules будут полностью поддерживаться во всех браузерах, которые вы поддерживаете нужно будет только полифил отключить (ну или, если в shim-mode использовать, то ещё кастомный тип для importmap поменять) и всё продолжит работать уже нативно...
<script type="importmap-shim">
// поменять на
<script type="importmap">А для решения "остаточных проблем" с кэшем, кажется правильнее и удобнее было бы https://github.com/single-spa/import-map-deployer использовать. Он позволяет после деплоймента каждого микрофронтенда обновить importmap.json с новыми путями и не понадобится хак с предварительной загрузкой манифестов для каждого МФЕ.
Гайд по микрофронтендам на single-spa, или Как уже наконец-то уйти от монолита во фронтенде