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

[Redjik]

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

У меня сходу два варианта решения.

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

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

 

[c0dex]

Я бы делал п.2

 

[Valick]

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

 

[AmdY]

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

 

[WMix]

запомнить id/ts последнего сообщения и при подписке его передать

 

[AmdY]

запомнить id/ts последнего сообщения и при подписке его передать

последнее сообщение могут удалить.

 

[WMix]

че изменится для подписки? ну нет его и нет

 

[MiksIr]

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

 

[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]

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

Тогда есть ли смысл делать точку на получение данных, если можно в подписке указать какой то период или лимит.

 

[grigori]

конечно, соскучился уже по разговору без снобизма

раз есть события, это всегда AP схема.

я бы не ставил между ними знак равенства, репликация - тоже подписка, и это CP, и в mysql, и в блокчейне

 

[Redjik]

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

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

Log-Shipping Standby Servers

www.postgresql.org

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

 

[grigori]

да, асинхронная - это AP

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

 

[MiksIr]

Тогда есть ли смысл делать точку на получение данных, если можно в подписке указать какой то период или лимит.

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

 

[grigori]

Вань, по сути вопроса, ответ зависит от бизнес-логики.

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

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

 

[grigori]

Мне кажется логичным разделить подписки/отписки и получение данных. (Сейчас все в куче) Тупо SRP.
Этим апи будет пользоваться веб клиент, iOS клиент, android клиент.

Для этой задачи я вижу тупой, как валенок, REST. Разделять подписки/отписки и получение данных по разным endpoint - да, конечно, идемпотентность.
Или что ты имеешь ввиду под "сейчас все в куче"?

 

[grigori]

Тогда есть ли смысл делать точку на получение данных, если можно в подписке указать какой то период или лимит.

конечно, получение - идемпотентный запрос, а подписка - неидемпотентный