Поделиться ссылкой к сожалению не могу, эту информацию слышал в подкасте с кем-то из uber engineering, они сделали какую-то свою платформу на основе long polling... погуглив нашел RAMEN
Кстати, компания X. Проектировать решение, где вы изначально закладываете long polling с мобильного приложения, ну такое себе удовольствие. Есть вообще-то вебсокеты или SSE(Server Side Events).
насколько я помню проводились исследования по потреблению энергии устройствами при long polling и websockets, и long polling с интервалом > 1 сек, значительно меньше потреблял энергии... Особенно актуально когда девайс в движении например с 2g сетью
Если мне не изменяет память, то телеграм построен именно с long polling'ом
Меня всегда интересовал вопрос о том как правильно обрабатывать интеграционные события синхронно в рамках основной транзакции БД ? Допустим в монолите есть модуль, который по доменному событию должен что-то атомарно обновить в БД и это обновление мы хотим тот час же включить в ответ обрабатываемого запроса
Сам буквально пару недель назад попал в такую же ситуацию, расшарил в ишьюсах свое виденье АПИ для DB::afterCommit хуков, получил в ответ: «мы не будем пока это реализовывать». Через 2 дня такая же реализация с небольшм переименованием была влита в мастер
Давно присматривался к Вашей работе, как замене для github.com/tlaverdure/laravel-echo-server, тогда как раз не хватало нативных для Laravel функций авторизации каналов, поэтому написал свой вариан echo-server на Go.
да, по сути в magento 2 это обычные middleware, подход мне нравится, хоть и довольно тяжелый в дебаге, например многими любимый guzzle использует такой подход без кодогенерации
кстати хороший пример composite это symfony form компонент, там как раз отдельный элемент формы и форма реализуют один интерфейс (методы setData, submit etc.)
Тоже заметил данную неточность. Еще по моему мнению пример декоратора также не верен, так как не показывает основное отличие декоратора и прокси, а именно добавление нового поведения/функционал к объекту. В примере показан обычный прокси. Классический пример декоратора div/table renderer для элементов формы имеет более «человеческое» лицо
Кстати, правильно ли я понимаю что судя по коду контейтера, после его отображения и запроса данных через XHR, компонент еще крутит индикатор загрузки? никак не боролись с задержкой транзишина на новый роут до подгрузки критичных данных? например redux-async-connect
код
if (!this.props.firstLoad) {
this.props.loadManagers(this.props.location);
}
Поделиться ссылкой к сожалению не могу, эту информацию слышал в подкасте с кем-то из uber engineering, они сделали какую-то свою платформу на основе long polling... погуглив нашел RAMEN
насколько я помню проводились исследования по потреблению энергии устройствами при long polling и websockets, и long polling с интервалом > 1 сек, значительно меньше потреблял энергии... Особенно актуально когда девайс в движении например с 2g сетью
Если мне не изменяет память, то телеграм построен именно с long polling'ом
Меня всегда интересовал вопрос о том как правильно обрабатывать интеграционные события синхронно в рамках основной транзакции БД ? Допустим в монолите есть модуль, который по доменному событию должен что-то атомарно обновить в БД и это обновление мы хотим тот час же включить в ответ обрабатываемого запроса
Суть пакета в $userId % $numOfVairants
Есть парочка вопросов:
этот подход называется duck modules
с остальным согласен более чем полностью!
this.props.loadManagers(this.props.location);
}