Для этого как раз можно использовать шину событий, и если один микрофронт уже запросил юзера, он отправляет инфу в топик, другие подписанные уже получают юзера оттуда и не запрашивают.
Второй вариант: запрашивать на хосте и прокидывать вниз в микрофронты, в данном случае от хоста независимости не будет, но опять же это можно фоллбэком обмазать и таки запрашивать, если с хоста не пришло.
P.S. В большом проекте, где много разных разработчиков нужны стандарты кодирования, чтобы разные куски были написаны одинаково и разработчик мог легко разобраться в чужом коде. Чем больше стандартов, тем больше одинакового кода. Чем больше одинакового кода - тем больше кандидатов или на генерацию или на вынесениюе в инфраструктурную библиотеку.
Ну если уже всё настолько плохо - то да. Тут лучше умыть руки, чем пытаться исправить. А когда у проекта есть техдир и яндекс карты используются везде одной версии - то можно просто запрещать всем командам тащить себе новую версию, и планировать централизованные апдейты.
Иногда нет бюджета везде заменить, тем более, что там (особенно с учетом неочевидной кластеризации и не только) достаточно много делов на апдейт.
Именно так в реальной жизни (а не книгах и статьях) чаще бывает - нужен одновременный релиз кучи всего, а не как в синтетических примерах, где новая фича требует обновления только Госуслуги.Авто, а всё остальное работает как и прежде.
Встречал и тот, и другой подход. Так что да, нужно выбирать архитектуру и инструменты в зависимости от задачи.
Весь этот объем работ ничего не принесет бизнесу и за него особо никто не заплатит в моменте, это нужно делать постепенно. По поводу генерации из метеданных — для больших админок работает, а когда это витринный b2c проект с ssr, то замучаешься генерировать.
Сейчас в мире такое происходит, что о будущем сложно в принципе думать в разрезе дальше полугода. На айти планировании это тоже сказывается.
Спасибо за отзыв! :3 Панацеей точно ничего не может быть, всегда бывают нюансы. По поводу разных фреймворков — я сбоку видел проект на SingleSPA, работало хорошо, но сам такое не проектировал.
При таком раскладе, естественно, всё будет через одно место. Интересно, где был их техдир, по мере того как оно росло до такой степени (начиналось же всё хорошо, как обычно). Уволить за профнепригодность.
Проекту больше 5 лет, техдиры были не всегда и их сменилось много, это буквально легаси потому что легаси.
Так, может, и не надо тогда позволять "использовать те зависимости, которые им удобны и необходимы" - и не будет боли?
Ну микрофронты разные, где-то есть яндекс.карты, где-то их нет, где-то эти яндекс.карты версии 2, а где-то уже версии 3. Вариантов же миллиард, реальная жизнь немного сложнее чем книги от O'Reilly и их ванильные примеры.
А разве где-то она есть - реальная необходимость в независимых релизах? Да, с одной стороны, заказчики/пользователи могут требовать новый футер через неделю, а новую корзину в апреле, но с другой - их требования 100% не всегда/редко/никогда будут один-в-один биться с границами ваших микрофронтендов (они ведь даже не знают, где эти границы проходят).
Конечно есть, представь просто, что условные Госуслуги.Авто вообще ничего не знают про существование Госуслуги.Паспорта, например. При этом для пользователя это вообще одни Госуслуги.
Вот это - самый главный вопрос, а всё остальное второстепенно и просто. Взаимодействие друг с другом и переиспользование общего кода.
Так да, микрофронты могут шерить все, что общее через либы, отличное решение. Называть ли при этом каждый микрофронт либой? Скорее какой-то религиозный вопрос, библиотека — что-то утилитарное и переиспользоуемое. Микрофронт — самостоятельное приложение, со своим стором, компонентами, доменной областью. Ну при этом вполне возможно, что мы имеем ввиду одно и то же, называя это разными названиями.
А почему билдтайм решение не годилось? Я буквально делал экземпляр раутера хостовый и каждый микрофронт при инициализации добавлял свои рауты и собственно когда мы доходили до рендеры можно было отлично понимать что и как. В рантайме такое сделать сильно сложнее, но может быть ивенты попробовать и сообщать в микрофронты какой раут должен быть открыт с какими параметрами?
1) Ну значит это осознанно, все причины на самом деле имеют право на существование. Поэтому желаю удачи в интеграции!
2) Не уверен, что многое из этого в принципе легко гуглится, особенно на русском, так что всегда рад подсказать! Лично мы это сами изобрели просто, без гугления.
Привет! Поднимать у себя хостовое приложение на дев-сервере, подключать необходимые микрофронты через link, если это buildtime, собирать локальную модуль федерацию в случае если это runtime. Очевидно всегда есть нюансы, это в общем.
1) А почему хочет именно модульную федерацию? Чем аргументирует? В теории это можно сделать через shared, но в этом случае «независимость» будет условная, сценарий выглядит как неоптимальный, но точнее можно сказать если уточнишь почему просят именно модуль федереацию.
2) Те два варианта, что ты назвал — нормально абсолютно, через bun link или npm link залинкованные пакеты, ты поднимаешь хост приложение, меняешь только сурсы микрофронта, но дев сервер у тебя реагирует быдто бы меняется хостовое (потому что меняется зависимость) и ведешь разработку. Так можно и сразу несколько микрофронтов разрабатывать, а потом просто пушить изменения в соответствующие репы.
Еще один вариант — режим «хоста» у любого микрофронта, то есть сборка и деплой на отдельный стенд в режиме standalone приложения, тоже рабочая схема, отдельные скрипты в package.json настраиваешь и вперед.
Это, безусловно, прекрасно. Но я все ещё мыслю в перспективе нескольких лет: что будет с поддержкой, будет ли заменяемость специалистов и прочие штуки. Где и как быстро мне нанять людей под это дело и как сильно нужно удерживать уже существующих. Ничего личного, просто бизнес.
Интересно получилось, ждем следующего сравнения с Sora от OpenAI, она тоже очень недурно делает!
Отличный вопрос, спасибо!
Для этого как раз можно использовать шину событий, и если один микрофронт уже запросил юзера, он отправляет инфу в топик, другие подписанные уже получают юзера оттуда и не запрашивают.
Второй вариант: запрашивать на хосте и прокидывать вниз в микрофронты, в данном случае от хоста независимости не будет, но опять же это можно фоллбэком обмазать и таки запрашивать, если с хоста не пришло.
Тут согласен на все 💯
Иногда нет бюджета везде заменить, тем более, что там (особенно с учетом неочевидной кластеризации и не только) достаточно много делов на апдейт.
Встречал и тот, и другой подход. Так что да, нужно выбирать архитектуру и инструменты в зависимости от задачи.
Весь этот объем работ ничего не принесет бизнесу и за него особо никто не заплатит в моменте, это нужно делать постепенно. По поводу генерации из метеданных — для больших админок работает, а когда это витринный b2c проект с ssr, то замучаешься генерировать.
Сейчас в мире такое происходит, что о будущем сложно в принципе думать в разрезе дальше полугода. На айти планировании это тоже сказывается.
Спасибо за отзыв! :3 Панацеей точно ничего не может быть, всегда бывают нюансы. По поводу разных фреймворков — я сбоку видел проект на SingleSPA, работало хорошо, но сам такое не проектировал.
Проекту больше 5 лет, техдиры были не всегда и их сменилось много, это буквально легаси потому что легаси.
Ну микрофронты разные, где-то есть яндекс.карты, где-то их нет, где-то эти яндекс.карты версии 2, а где-то уже версии 3. Вариантов же миллиард, реальная жизнь немного сложнее чем книги от O'Reilly и их ванильные примеры.
Конечно есть, представь просто, что условные Госуслуги.Авто вообще ничего не знают про существование Госуслуги.Паспорта, например. При этом для пользователя это вообще одни Госуслуги.
Тут согласились 🤝
Так да, микрофронты могут шерить все, что общее через либы, отличное решение. Называть ли при этом каждый микрофронт либой? Скорее какой-то религиозный вопрос, библиотека — что-то утилитарное и переиспользоуемое. Микрофронт — самостоятельное приложение, со своим стором, компонентами, доменной областью. Ну при этом вполне возможно, что мы имеем ввиду одно и то же, называя это разными названиями.
А почему билдтайм решение не годилось? Я буквально делал экземпляр раутера хостовый и каждый микрофронт при инициализации добавлял свои рауты и собственно когда мы доходили до рендеры можно было отлично понимать что и как. В рантайме такое сделать сильно сложнее, но может быть ивенты попробовать и сообщать в микрофронты какой раут должен быть открыт с какими параметрами?
Было дело, делали, но его тоже нужно поддерживать, поэтому здесь всегда есть вопрос рентабельности.
Тоже классно, кстати, да.
1) Ну значит это осознанно, все причины на самом деле имеют право на существование. Поэтому желаю удачи в интеграции!
2) Не уверен, что многое из этого в принципе легко гуглится, особенно на русском, так что всегда рад подсказать! Лично мы это сами изобрели просто, без гугления.
Что-то на энтерпрайзном, негибком и без реактивных фреймворков. Нам, любителям смузи, не подойдет. =)
Привет! Поднимать у себя хостовое приложение на дев-сервере, подключать необходимые микрофронты через link, если это buildtime, собирать локальную модуль федерацию в случае если это runtime. Очевидно всегда есть нюансы, это в общем.
Привет!
1) А почему хочет именно модульную федерацию? Чем аргументирует? В теории это можно сделать через shared, но в этом случае «независимость» будет условная, сценарий выглядит как неоптимальный, но точнее можно сказать если уточнишь почему просят именно модуль федереацию.
2) Те два варианта, что ты назвал — нормально абсолютно, через bun link или npm link залинкованные пакеты, ты поднимаешь хост приложение, меняешь только сурсы микрофронта, но дев сервер у тебя реагирует быдто бы меняется хостовое (потому что меняется зависимость) и ведешь разработку. Так можно и сразу несколько микрофронтов разрабатывать, а потом просто пушить изменения в соответствующие репы.
Еще один вариант — режим «хоста» у любого микрофронта, то есть сборка и деплой на отдельный стенд в режиме standalone приложения, тоже рабочая схема, отдельные скрипты в package.json настраиваешь и вперед.
Спасибо за вопросы!
Братва, жизнь все расставит по местам. И по вакансиям, и по фреймворкам.
Всем успехов найти ту работу и тот инструмент, который вам подойдет. =)
С мобилы ничего непонятно :<
Это, безусловно, прекрасно. Но я все ещё мыслю в перспективе нескольких лет: что будет с поддержкой, будет ли заменяемость специалистов и прочие штуки. Где и как быстро мне нанять людей под это дело и как сильно нужно удерживать уже существующих. Ничего личного, просто бизнес.
Понял, про Карловыча слышал только мемы, мы больше на всемирное комьюнити ориентировались пока писали, локальные штуки не так интересны.
Я может сейчас фронтенд-скуфом буду выглядеть, но что такое мол?