Комментарии 16
Интересно пойдёт ли эволюция дальше. Микро сервис поделится на нано сервис и т. д
Привет! Спасибо за статью! Не было опыта наладить взаимодействия через бэк по веб-сокетам? Чтобы например хранить какую-то информацию. Допустим настройки пользователя (чтобы все было одинаково на разных платформах) ну или другие данные. То есть у нас есть 2 и более приложения и каждое из них устанавливает веб-сокет соединение с бэкендом и таким образом все работает без участия шины событий (ну или она будет выступать как дублирующей на случай медленного интернета)
Если каждое приложение будет устанавливать веб-сокет то сервер очень легко может прилечь а если открыть пару тройку вкладок одного и того же сайта где такое решение реализовано то проблема увеличиться как n*k где n это количество вкладок а k это количество приложений внутри каждой вкладки.
Если вынести установку вебсокет соединения условно в тот же самый Shared Worker, то мы уберем из формулы n. Этим решим проблему плодящихся подключений. И если в эту схему еще добавим шину событий, то теоретически можно добиться 1 вебсокет подключения на все вкладки и микрофронты
Можно но это сильно зависит от того сколько событий Вы собрались отправлять и их размер. Трафик от всех вкладок может быть большим и тогда один вебсокет будет не самой хорошей идеей особенно если его сеансы влияют на интерактивность UI. Т.е. я нажал на кнопку и ничего не произошло либо включилась крутилка и зависла.
Привет! Интересный вопрос. Не очень понятна мотивация походов на бэк для обмена данными двух микрофронтендов, которые работают в контексте одного приложения обертки.
"Более общим решением будет связать микрофронтенды через хост-приложение, например создав сервис, где мы опишем, какие МФ есть в приложении, и их API. Так сами микрофронтенды не будут знать о существовании друг друга, но хост-приложение должно уметь обрабатывать их запросы." мне кажется или это противоречит идее микрофронтендов? У Вас получается god-object "хост-приложение" которое обо всех все знает хотя по факту должно быть наоборот. "Хост-приложение" в теории вообще не должно ничего знать а просто загружать требуемые модули.
"В микрофронтенде мы используем метод отправки события и саму шину берем из хост-приложения через синглтон InjectionToken" начнем с того что браузер уже из коробки имеет реализацию событийно-ориентированного подхода. Также шина добавляет целый кластер новых проблем. Как понять что произошла ошибка в action-е и вообще он выполнился? Если не выполнился стоит ли попробовать повторить? Что если ошибка произошла в самой шине? Что если нужно не просто кейс по типу "кликнули на что-то и надо что-то выполнить" а сложнее по типу "дай мне информацию о то то о чем знаешь только ты"? Что если надо выполнять по цепочке несколько вызовов?
God-object, прям в точку. Но как иначе без шины, вроде самый простой и логичный вариант?
Про то как понять, что произошла ошибка в Actions и видеть его прогресс так такие проблемы стали возникать с приходом web sockets. (появились дополнительные actions=)))
На счет God-object TrueRomanus все правильно пишет, поэтому такое решение у нас не используется.
По поводу ошибок - в шину передается сервис логирования который например кидает ошибки в консоль или как-то еще обрабатывает, в зависимости от пожелания потребителя шины.
Про более сложный кейс не очень понял вопрос. Цепочку вызовов можно реализовать когда предыдущий экшн триггерит следующий.
Я имел ввиду когда два приложения могут делиться какими-то знаниями уникальными для друг друга. Т.е. есть два приложения - приложение с заказом карт и приложение с подарками. Допустим при заказе карты я получаю подарок и бизнес кейс что я перехожу с одного приложения на другое но при этом они вполне могут обменяться данными. Приложение подарков может получить информацию о карте (название например) и отобразить название карты и еще что-то плюс подарок. Простите если пример странный, пытался придумать что-то по Вашему профилю.
Привет, а пробовали ли вы стор, например редакс, прокидывать в дочерние модули?
Или контексты?
Пробовал, вроде неплохо работает
Как мы решили проблему общения микрофронтендов в приложении