Веб-мессенджеры и эвент 'beforeunload': как сохранить миллион сообщений при закрытии страницы

[maxsolovev]

Ваш текст so cute. Write ещё :)

[grigoryvp]

Англицизмы? ИМХО, разработчикам с ними проще читать.

[maxsolovev]

Я разработчик, мне не проще (имхо).
Приведу пример из вашего же текста.
Нормально: «В конце лета мы добавили в наше облако Voximplant поддержку месседжинга».
Странно: «В этом году мы планируем существенно расширить наш messaging».
Ну, и в целом, одно дело, если это название технологии, другое, — писать «conversation».

[grigoryvp]

Я долго думал над адекватным переводом «Conversation». «Чат»? Но если на двоих — это нифига не чат. «Беседа»? «Канал»? Нет хорошего перевода.

[beatleboy]

Диалог?

[grigoryvp]

Между двумя. А в conversation можно тыщу запихнуть и сделать аналог «Channel» или «Group» в телеграме.

[inoyakaigor]

Проблема отпадёт, если вы признаете где-то у себя внутри, что на двоих это тоже чат. :)

[maxsolovev]

Беседа — самое оно :)

[Germanets]

И беседа, и канал, и диалог — вполне нормальные варианты, каждый из которых используется в существующих мессенджерах\соц сетях… Другой вопрос, что «Conversation» тоже вполне себе удобоварим для человека, который знает перевод слова и привык обсуждать код с коллегами, используя имена классов. Разве что для тех, кто перевода не знает, можно было в пером случае указать и перевод в скобках, чтоб и ежу понятно было)

[grigoryvp]

Легко:

[c4boomb]

Выдуманная проблема.
В среде разработчиков большинство привыкло общаться с использованием названий классов.
В 99% случае названия классов на английском.
В чем проблема?

[c4boomb]

Посмотрел историю ваших комментариев там и "экзампловые", и "непофикшенный", и "бранч"

[Slysar7]

Скайп очень часто подвисает при использовании, как и все продукты майрософт. Да и в целом он уже больше подходит для видеозвонков и отживает свое. В плане оперативной беседы с пользователем и интеграцией с CRM я бы посоветовал интегрировать сервис типа chat2desk.com — насколько я помню он поддерживает в районе 5 мессенджеров

[c4boomb]

Вы бы перед тем как оставлять коммент посмотрели о Skype ли статья

[darklog]

А что произойдет если _seq превзойдет MAX_SAFE_INTEGER?

[grigoryvp]

А на сервере ограничение на количество обновлений от одного клиента в минуту :) За 100 лет не произойдет, не переживайте. Они же не на всю систему, а только для conversation уникальны.

[meremin]

Почему не timeuuid? Если причина не в оптимизации трафика? Кто счётчик увеличивает, приложение или база?

[grigoryvp]

В эвенте уже есть timestamp — зачем две разные сущности в одну запихивать? Увеличивает, конечно же, сервер.

[meremin]

Прост как будете поддерживать консистентность счетчика, если у вас будет больше 1 сервера?
На уровне балансировщика, привязывать чат к серверу?

[grigoryvp]

У нас намного больше одного сервера :) Это не самая сложная техническая проблема.

[meremin]

Согласен. И все же как ее решили, если не секрет? Очень интересен ваш опыт.
Мы вот именно по причине распределённости системы выбрали uuidv1. А вернее ему подобную реализацию с сортировкой. Плюсов много: уникальность в рамках всей системы, содержит метку времени, сортировка. Но вот есть существенный для нас минус: существенно увеличивают размер пакета при обмене данными с клиентом.
Как идея — отдельный микрометрами, который будет заняться увеличением счетчика.

[meremin]

• микросервис

[grigoryvp]

Непосредственно у нас — шардинг. Но, как я уже говорил, есть множество разных способов и нужные выбирается под архитектуру, требования итд. У нас, к примеру, sequence id уникальны только в рамках conversation.

У timeuuid есть вопросы к синхронизации времени между серверами и задержками между сообщениями. Эвенты разные бывают, и если быстро случилась последовательность, к примеру, «отправил сообщение а затем вышел из канала» то хочется чтобы они были именно в такой последовательности, иначе возможно странное :)

[blackswanny]

проблема beforeunload в том, что он не работает для всех случаев и для всех браузеров. В IOSafari при refresh page он не срабатывает. Методы с localStorage или IndexDB не надежны, так как браузер успеет прервать код исполнения javascript. Если послать ajax, то многие браузеры, особенно мобильные, обрывают соединение закрытой страницы со стороны клиента, но запрос вы успеете послать и сервер скорее сделает свое дело (нужна проверка на больших запросах)

[grigoryvp]

Все верно. Тем не менее, большинство крупных игроков вроде Google Docs им активно пользуются!