Track collapsable client events, that are handled optimistically (#444) #768
Conversation
09b2405 to
35b2b8b
Compare
- rename EventsPool to OptimisticEventsPoolService and move to domain/service/optimistic_event_pool.dart - add event pool to prorerties and constructors of ChatRepository, MyUserRepository, HiveRxChat - update dependency injection in routes and tests
|
@SleepySquash
Ключ события в данном случае - тип события и ид пользователя. Если запросы по этому ключу выполнять параллельно. то о 8000 ни выполнятся в произвольном порядке и статус избранности на сервере может отличаться от статуса на клиенте. Выполнять последовательно вообще все запросы к серверу ухудшит производительность. Сервер присылает событие. Возможно мы добавили чат в избранное в другом сеансе, возможно в этом. Событие игнорируется только если мы его отразили в интерфейсе и оно успело отправить запрос на сервер. Тогда оно попадает в список ожидающих игнорирования. Если пользователь меняет статус 10 раз, пока первое событие еще не обработано сервером, нет смысла слать 10 событий на сервер. События с одинаковым ключом могут отменять друг друга. На сервер будет отправлено только первое событие и возможно последнее. Классы событий расширены методом создания PoolEntry. Т.к. классы событий пользователя и чата не связаны между собой, они имеют отдельные расширения. Для создания PoolEntry указывается способ расчета ключа и хеша значимых полей события. Вся логика сосредоточена в классе OptimisticEventsPoolService, для подключения события к этому механизму
|
|
@Alienjob, во-первых, это 100% не сервис, потому что разве это бизнес-логика? В доменной области "мессенджер" нет понятия "сервис событий", это не относится к сервисам. Это деталь реализации стора, только стор об этом и знает. Соответственно, такая структура будет утилитой, но не сервисом. Утилита может создаваться в каждом сторе, в неё будут кормить сторы свои события и действия для последовательной обработки, которую Вы описали. Во-вторых, актуальность такой структуры в целом звучит адекватно. Нам нужно не просто "не обрабатывать события, которые обработали оптимистично", но и исключить спам таких оптимистичных действий, чтобы на бэкэнд не отправлять миллионы однотипных ивентов - как в звонке, например, при поднятии/опускании руки, если не ошибаюсь. Но этот механизм - это по сути debounce, в |
|
@Alienjob, т.е. у меня пока претензия к реализации - мне кажется, что она излишне сложная. Но не буду утверждать, что можно проще, буду только просить Вас, пожалуйста, попробовать её упростить максимально сильно. |
This reverts commit e4ee0f8.
- remove EventMode - make toPoolEntry method more kind-centred - implement == for PoolEntry
|
FCM |
|
@SleepySquash Постарался максимально упростить реализацию. Сейчас в ней нет как такового
Можно было бы дополнительно упростить реализацию если
|
Resolves (#444)
Synopsis
Локально инициированные события обрабатываются оптимистично. Запросы на их обработку выполняются не последовательно. Может происходить ситуация, когда с бека приходит неактуальная мутация.
Solution
При оптимистичной обработке события добавлять добавлять такое событие в специальный пул. Этот пул будет следить за тем, чтобы конкурирущие события были доставлены на бек последовательно.
Так-же при получении с бека события следует проверять - было ли оно обработано оптимистично (хранится ли оно в пуле) и игнорировать такие события. Возможно от эту часть правильнее поручить беку - не присылать мутации по событиям, которые инициировала эта сессия.
Checklist
k::labels applied