OS
Ох, надежные решение на хазелкасте - это не просто, а персистанса там, можно сказать, нет.
Ты как-то мягко сформулировал :)
Size: a a a
2020 November 20
PD
Ну, я же вообще мягко формулирую )
IB
Хм, а как у тебя реактивный движок на фронте будет подключаться к этому "состоянию данных"? Или у тебя нет такой задачи?
Очередь, конечно, есть, но только пока есть сессия. Подключился (subscribe) - тебе пошли push'и с обновлениями state'а. Отключился или порвалась связь - ну и хрен с тобой.
PD
Igor Bespalchuk
Очередь, конечно, есть, но только пока есть сессия. Подключился (subscribe) - тебе пошли push'и с обновлениями state'а. Отключился или порвалась связь - ну и хрен с тобой.
Вот это "порвалась связь" меня и печалит...
IB
Обнаружился backpressure - ну, пореже тебе обновления будут слать.
IB
Если тебя это печалит, то, скорее всего, задача у тебя совсем другая.
PD
Т.е. клиент въехал в туннель - и опаньки, уже нотификация не дойдет?
IB
Как выедет - переподключится и получит последнее состояние
PD
Ну, это дороговато может быть (зависит, правда, от того, как там сделано переподключение и кластеризация). Ну и состояние - не всегда то, что нужно. Чаще нужен именно stream от сервера, его проще замкнуть на реактивные движки на фронте.
PD
А сейчас все-таки все архитектуры фронтенда - вокруг реактивщины крутятся
IB
Если тебе нужно точно сохранить очередь всего, что отправлялось конкретному клиенту - то наверное тебе нужно решение другого типа. Может, в DSS это и есть где-то, но сомневаюсь, т.к. мне кажется это принципиально другой подход - "_current_ data distribution" vs "message queueing"
IB
"Чаще нужен" - вот это как раз и есть "зависит от задачи".
IB
Вопрос целостности, нерразрывности, этого стрима (возможны ли пропуски на период отсутствия связи). Нужна ли тебе вот эта неразрывность исходного потока или только поток актуальных в моменте состояний.
IB
Если только актуальное нужно - ну переподключилось оно само и пошел тебе стрим снова...
IB
А вот если тебе через клиента обязательно всю историю прокачать надо.... тогда это, наверное, другая концепция. Впрочем, х.з., может кто-то из DSS-семейства и это может.
PD
Igor Bespalchuk
Если только актуальное нужно - ну переподключилось оно само и пошел тебе стрим снова...
Я все равно не понимаю, как из "распределенного стейта" получить "стрим".
Т.е. понятно, что в качестве распределенного состояния у меня может быть как раз "список актуальных событий для данного клиента", но как у меня фронтенд будет реагировать на изменения этого стейта, там все равно нужен же какой-то листенер.
Да, у меня задачи в основном - реакция пользовательского интерфейса на события с сервера.
Т.е. понятно, что в качестве распределенного состояния у меня может быть как раз "список актуальных событий для данного клиента", но как у меня фронтенд будет реагировать на изменения этого стейта, там все равно нужен же какой-то листенер.
Да, у меня задачи в основном - реакция пользовательского интерфейса на события с сервера.
IB
Ну дык клиентское API это в первую очередь subscribe(topic-path) с обработчиком изменений. Что тут непонятного?
Но вот "состояние - список актуальных событий" звучит странно.
Но вот "состояние - список актуальных событий" звучит странно.
IB
Состояние в их всех примерах это, например, "дверь открыта или закрыта", "USD:BTC=X, etc"
IB
События (сообщения с дельтами состояний) - под капотом.
IB
И вот если реакция пользовательского интерфейса на самом деле - на изменения некоторого внешнего состояния, то становится очень просто - ты просто его биндишь к UI и все.
Все остальное делает middleware.
Все остальное делает middleware.