Не хочу уходить в дискуссию, но как-будто вы сразу поставили клеймо "просто они захотели новые технологии" на нашем решении.
Мы же, все-таки, все это делали ради продукта. Для меня правильно выстроенная архитектура - хороший технический продукт, который не ломается и удобен пользователю.
Теперь по пунктам: 1) Приложения независимы, но они могут шарить данные между собой. Если вам нужно отобразить данные сразу в нескольких микрофронтах - вы можете это сделать (описывал в статье)
2) Как по мне быстрый деплой - это в первую очередь про пользователя. Когда вам нужно быстро откатить баг, гораздо приятнее это сделать за пару минут, чем ждать несколько часов. На разработчика вообще непонятно как это влияет, я наоборот могу пойти за это время кофе попить и чем дольше, тем лучше ?
3) Вы написали "Лично я вижу хорошее решение "микрофронтендов" в модульности и едином строгом фреймворке-хосте". Так у нас, можно сказать, так и сделано. Есть единый хост, модули и свои паттерны. Может вас смутило упоминание сразу и Angular, и Vue. Еще раз повторю - мы не гнались за новыми технологиями, мы выстраивали правильную масштабируемую архитектуру на старом проекте и попутно его переписывали на новые технологии, которые нам кажутся удобнее.
Конечно, ты прав Если бездумно переписывать с одного фреймворка на другой, ничего для бизнеса ты не сделаешь
Конкретно у нас была проблема, что код устарел и имел ограничения, которые не позволяли масштабироваться продукту и быстро решать его проблемы
Переходя на микрофронты мы не просто меняем один фреймворк на другой, мы: 1) Рефакторим приложение и находим уязвимые места (не останавливая производственный цикл) 2) Даем возможность быстро создавать новые команды и микрофронты, не ломаю текущую функциональность 3) Само производство ускоряется, так как релизы становятся независимыми и быстрыми
Все 3 пункта положительно влияют как на разработчиков, так и на конечных пользователей
Ну тут уже какой-то негатив пошел) Наши цели я озвучил в начале статьи - отрефакторить большое приложение, переписать его на новые технологии + разделить на независимые сервисы.
Наоборот, нашим подходом мы лечим наш продукт и легко его масштабируем
iframe имеют много ограничений, на это уже есть доклады, можно глянуть их
Административный способ 100% работает, но работает в маленьких/средних компаниях (это чисто моя условные обозначения, приводить кол-во людей не буду ?)
Если компании уже большая ей очень важно, чтобы приложение было максимально стойким (теряют большие деньги все-таки). И если уже что-то отваливается, то пусть остальной функционал работает
Теперь привожу пример
Вася выкатил новую фичу, но тут, внезапно, отвалился раздел с заказами. Вася в шоке, ведь он трогал настройки склад, совсем другой раздел.
Ты можешь сказать "Как так, почему выкатили не рабочий функционал". Человеческий фактор никто не отменял, невозможно все учесть на 100% и провести регресс всего сайта для каждой фичи
Поэтому, чтобы минимизировать вот такие случаи, мы и делим наш код на отдельные сервисы
Продолжая ответ на вопрос: 1) "Если будут пересекающиеся вопросы\фичи - организовываем созвон и обсуждаем". Мы так и делаем, еще больше скажу - с микрофронтами это делать еще проще, так как у тебя расчерчены границы 2) "И также для локальной разработки очень часто нужно не рамки одного микрофронтенда" - ты можешь запускать как отдельный микрофронт, так и 2, так и все приложение целиком. Если я делаю кнопку в поддержке, мне раздел заказов (например) не нужен
Если кратко - это чуть разные вещи для разных задач.
Single-spa помогает выстроить архитектуру из независимых приложений, которые могут быть написаны на разных технологиях. Позволяет удобно организовать роутинг между ними и управлять состояниями.
Module federation - больше про шаринг модулей одного фреймворка. Допустим у тебя большое приложение на Vue, но ты его хочешь раздробить и распределить по отдельным репам. После настройки MF ты сможешь это сделать и главное будешь подключать код из этих реп как обычные компоненты (звучит оч удобно и круто)
Вообще эти подходы можно даже комбинировать. Ты тащишь себе в проект single spa, выстраиваешь архитектуру, а module federation тебе позволяет шарить какой-то общий код.
НО
Чтобы использовать MF сразу для разных фреймворков, нужно заморочиться и писать свои доп обертки, чтобы дружить проекты между собой и там, на самом деле, вытекает много подводных камней. И тут возникает вопрос, а зачем тогда накручивать все это на MF, если есть готовый single-spa
Суммируя текст выше - наша задача "перейти на новый фреймворк и сделать независимые приложухи", и мы выбираем single-spa, тк именно на этом он и специализируется
Не не не, у нас нет распределения 1 команда - 1 микрофронт ?
В каждой команде есть по 3-4 микрофронта (а то и больше) со своей бизнес логикой. Есть общие фронты (шапка, навигация, роутер), в них могут вносить изменения любые разрабы, если это подразумевается в задаче. Например сделал новую страничку в своем сервисе - добавил ее в общую навигацию.
По поводу вынесения шапки в отдельный микрофронт - вещь холиварная. То что мы теряем в оптимизации, это да, но зато получаем проект с легко читаемым кодом (что для программиста оч важно), независимый и быстрый деплой (в реалиях больших компаний тоже ключевой фактор) + защиту от случайных багов (шапка будет жить даже если один из разделов отвалится)
Во вьюшке нравится работа с реактивностью, много удобных экосистемных решений (типо стора, роутера). И в целом она нам кажется лаконичной и простой для восприятия
Не хочу уходить в дискуссию, но как-будто вы сразу поставили клеймо "просто они захотели новые технологии" на нашем решении.
Мы же, все-таки, все это делали ради продукта. Для меня правильно выстроенная архитектура - хороший технический продукт, который не ломается и удобен пользователю.
Теперь по пунктам:
1) Приложения независимы, но они могут шарить данные между собой. Если вам нужно отобразить данные сразу в нескольких микрофронтах - вы можете это сделать (описывал в статье)
2) Как по мне быстрый деплой - это в первую очередь про пользователя. Когда вам нужно быстро откатить баг, гораздо приятнее это сделать за пару минут, чем ждать несколько часов. На разработчика вообще непонятно как это влияет, я наоборот могу пойти за это время кофе попить и чем дольше, тем лучше ?
3) Вы написали "Лично я вижу хорошее решение "микрофронтендов" в модульности и едином строгом фреймворке-хосте". Так у нас, можно сказать, так и сделано. Есть единый хост, модули и свои паттерны. Может вас смутило упоминание сразу и Angular, и Vue. Еще раз повторю - мы не гнались за новыми технологиями, мы выстраивали правильную масштабируемую архитектуру на старом проекте и попутно его переписывали на новые технологии, которые нам кажутся удобнее.
Конечно, ты прав
Если бездумно переписывать с одного фреймворка на другой, ничего для бизнеса ты не сделаешь
Конкретно у нас была проблема, что код устарел и имел ограничения, которые не позволяли масштабироваться продукту и быстро решать его проблемы
Переходя на микрофронты мы не просто меняем один фреймворк на другой, мы:
1) Рефакторим приложение и находим уязвимые места (не останавливая производственный цикл)
2) Даем возможность быстро создавать новые команды и микрофронты, не ломаю текущую функциональность
3) Само производство ускоряется, так как релизы становятся независимыми и быстрыми
Все 3 пункта положительно влияют как на разработчиков, так и на конечных пользователей
Ну тут уже какой-то негатив пошел)
Наши цели я озвучил в начале статьи - отрефакторить большое приложение, переписать его на новые технологии + разделить на независимые сервисы.
Наоборот, нашим подходом мы лечим наш продукт и легко его масштабируем
iframe имеют много ограничений, на это уже есть доклады, можно глянуть их
Интересные мысли)
Административный способ 100% работает, но работает в маленьких/средних компаниях (это чисто моя условные обозначения, приводить кол-во людей не буду ?)
Если компании уже большая ей очень важно, чтобы приложение было максимально стойким (теряют большие деньги все-таки). И если уже что-то отваливается, то пусть остальной функционал работает
Теперь привожу пример
Вася выкатил новую фичу, но тут, внезапно, отвалился раздел с заказами. Вася в шоке, ведь он трогал настройки склад, совсем другой раздел.
Ты можешь сказать "Как так, почему выкатили не рабочий функционал". Человеческий фактор никто не отменял, невозможно все учесть на 100% и провести регресс всего сайта для каждой фичи
Поэтому, чтобы минимизировать вот такие случаи, мы и делим наш код на отдельные сервисы
Продолжая ответ на вопрос:
1) "Если будут пересекающиеся вопросы\фичи - организовываем созвон и обсуждаем". Мы так и делаем, еще больше скажу - с микрофронтами это делать еще проще, так как у тебя расчерчены границы
2) "И также для локальной разработки очень часто нужно не рамки одного микрофронтенда" - ты можешь запускать как отдельный микрофронт, так и 2, так и все приложение целиком. Если я делаю кнопку в поддержке, мне раздел заказов (например) не нужен
Если кратко - это чуть разные вещи для разных задач.
Single-spa помогает выстроить архитектуру из независимых приложений, которые могут быть написаны на разных технологиях. Позволяет удобно организовать роутинг между ними и управлять состояниями.
Module federation - больше про шаринг модулей одного фреймворка. Допустим у тебя большое приложение на Vue, но ты его хочешь раздробить и распределить по отдельным репам. После настройки MF ты сможешь это сделать и главное будешь подключать код из этих реп как обычные компоненты (звучит оч удобно и круто)
Вообще эти подходы можно даже комбинировать. Ты тащишь себе в проект single spa, выстраиваешь архитектуру, а module federation тебе позволяет шарить какой-то общий код.
НО
Чтобы использовать MF сразу для разных фреймворков, нужно заморочиться и писать свои доп обертки, чтобы дружить проекты между собой и там, на самом деле, вытекает много подводных камней. И тут возникает вопрос, а зачем тогда накручивать все это на MF, если есть готовый single-spa
Суммируя текст выше - наша задача "перейти на новый фреймворк и сделать независимые приложухи", и мы выбираем single-spa, тк именно на этом он и специализируется
Не не не, у нас нет распределения 1 команда - 1 микрофронт ?
В каждой команде есть по 3-4 микрофронта (а то и больше) со своей бизнес логикой. Есть общие фронты (шапка, навигация, роутер), в них могут вносить изменения любые разрабы, если это подразумевается в задаче. Например сделал новую страничку в своем сервисе - добавил ее в общую навигацию.
По поводу вынесения шапки в отдельный микрофронт - вещь холиварная. То что мы теряем в оптимизации, это да, но зато получаем проект с легко читаемым кодом (что для программиста оч важно), независимый и быстрый деплой (в реалиях больших компаний тоже ключевой фактор) + защиту от случайных багов (шапка будет жить даже если один из разделов отвалится)
Но выбирать, конечно, тебе)
Во вьюшке нравится работа с реактивностью, много удобных экосистемных решений (типо стора, роутера). И в целом она нам кажется лаконичной и простой для восприятия