Получение данных и подписка.

Redjik

Джедай-мастер
Возьмем для примера чат.
Сначала получаем данные, последние сообщения в чате, историю.
Потом подписываемся на новые сообщения (технология не важна, например вебсоккет).
Не нашел в интернетах, чтобы кого-то волновала проблема, что это не атомарные операции.
Следовательно между этими операциями может появиться сообщение, которое никак не обработается.
Прошерстил тонны ресурсов и разных опенсорс и ентерпрайз решений, все забивают. (может не там искал =)))

У меня сходу два варианта решения.
  1. Сначала подписаться на изменения, складывать их в буффер, после получения данных сделать replay. (умный клиент)
  2. Сначала получить данные, в ответе должен быть timestamp. В подписке указать timestamp с которого нужно получать данные об изменениях. (умный сервер, далеко не каждый умеет в retention period)

Есть еще варианты?
 

Valick

Новичок
3. подписался на сообщения, получил разом историю+новые сообщения
 

AmdY

Пью пиво
Команда форума
Скорее всего у тебя будет умный сервер и умный клиент. В наших кейсах таймстамп подходил, но потом пришлось добавлять логику на клиент для редактирования-удаления старых сообщений.
 

WMix

герр M:)ller
Партнер клуба
запомнить id/ts последнего сообщения и при подписке его передать
 

WMix

герр M:)ller
Партнер клуба
че изменится для подписки? ну нет его и нет
 

MiksIr

miksir@home:~$
Второй конечно, как ты иначе реконекты отрабатывать будешь. Первый вариант не особо проще, а для реконектов вообще в ад превратится.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Не нашел в интернетах, чтобы кого-то волновала проблема, что это не атомарные операции.
Прости, но ... Бугагага. А есть ли в интернете хоть что-то старше, чем эта тема? Я повторяю это название каждый раз на каждой задаче в каждой команде, и все как-бы когда-то слышали, но в упор забывают. И ты, Брут :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
У меня сходу два варианта решения.
  1. Сначала подписаться на изменения, складывать их в буффер, после получения данных сделать replay. (умный клиент)
  2. Сначала получить данные, в ответе должен быть timestamp. В подписке указать timestamp с которого нужно получать данные об изменениях. (умный сервер, далеко не каждый умеет в retention period)

Есть еще варианты?
Решений всегда три, кэп :)
1. Eventual consistency - загружаем историю, подписываемся, дотягиваем пропущенное. AP-решение (Availability+partition tolerance).
2. AC-решение, жертвуем partition tolerance. Iframe refresh, древние чаты. (2 phase commit? ))).
3. Push-им все сообщения за N часов в любом порядке как граф с указанием соседних ID, и дотягиваем пропуски - блокчейн-модель, СP-решение.
 
Последнее редактирование:

Redjik

Джедай-мастер
Гриша как всегда, любишь набросить на вентилятор ))) Я не забываю про CAP. Просто к этой теме она имеет опосредованное отношение. В описании задачи четко указано, что есть подписка на события. А раз есть события, это всегда AP схема.

Тему я создал, чтобы посмотреть на подходы решения проблемы с eventual consistency той самой, в AP системах.
 

Redjik

Джедай-мастер
Конкретно в моем случае, был чат на firebase, писали чисто фронты и как могли.
Пришла задача на регистрацию приложения в росцифре, firebase попал под санкции. Временное решение сделали, убрали его на сервак, а фронт пересадили на socketio, сохранив сигнатуру вызовов.
Теперь появились ресурсы, чтобы сделать нормальный api. Мне кажется логичным разделить подписки/отписки и получение данных. (Сейчас все в куче) Тупо SRP.
Этим апи будет пользоваться веб клиент, iOS клиент, android клиент.
Думаю как сделать удобный апи для трёх команд разработки.
 

Redjik

Джедай-мастер
Второй конечно, как ты иначе реконекты отрабатывать будешь. Первый вариант не особо проще, а для реконектов вообще в ад превратится.
Тогда есть ли смысл делать точку на получение данных, если можно в подписке указать какой то период или лимит.
 

Redjik

Джедай-мастер
Асинхронная репликация, построеная на ивентах, AP (1 - лаг репликации, 2 - мастер не знает, что там с репликой, и не будет откатывать транзакцию, если она не зафиксировалсь в реплике)

Синхронная репликация, построенная на апи, AC (1 - нет лага, 2 - если слейвы не отчитались о фиксации данных, данные не сохраняются в мастере)


с блокчейном примерно такая же логика
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
да, асинхронная - это AP

че-то протупил только проснувшись, еще подумаю над тезисом про AP и подпиской )))
 

MiksIr

miksir@home:~$
Тогда есть ли смысл делать точку на получение данных, если можно в подписке указать какой то период или лимит.
Если чаты короткие, а-ля поддержка, то может и не надо. Если же история большая - то отдельный метод полезен для загрузки прошлого, да и при первом входе - попросить 10 последних сообщений, например, а потом уже подписка с таймстампом/id последнего
В общем исходя из требований.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Вань, по сути вопроса, ответ зависит от бизнес-логики.

Вы чат продаете, или только показываете?
То есть, какой уровень гарантии доставки сообщений требуется обеспечить?

Если продаете - например, чат для учителей с учениками, при подключении запрашиваешь клиентом манифест списка сообщений, и тянешь по списку через REST API.
Сквозной GUID сообщений assumed. В браузере сообщения можно писать в IndexedDB по ID.
Если бесплатно показываете для фана или саппорта - забей.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Мне кажется логичным разделить подписки/отписки и получение данных. (Сейчас все в куче) Тупо SRP.
Этим апи будет пользоваться веб клиент, iOS клиент, android клиент.
Для этой задачи я вижу тупой, как валенок, REST. Разделять подписки/отписки и получение данных по разным endpoint - да, конечно, идемпотентность.
Или что ты имеешь ввиду под "сейчас все в куче"?
 
Сверху