Realtime-чат без WebSocket: long-polling, гонки переподключения и дубли пушей

[Void-Cowboy]

вроде ж была уже такая статья недавно?

и собсвенно по теме статьи - если это приложение то можно grpc юзать для такого (это даже лучше)

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

[vientooscuro]

Да, её почему-то перенесли в черновики, я доработал

[vientooscuro]

Да, я дополнил про grpc в статье. У нас был уже готовый большой сервис на long-polling – это было решение CTO, а отдельный реалтайм-чат мы в тот момент не планировали под наше приложение, была только идея прикрутить чат того сервиса. А потом перенесли чаты, уперлись в ограничения архитектуры (к примеру, в групповых чатах все сообщения хранились в N-копиях, и пока групповые чаты были небольшими - 2-4 человека, - это было ок, а вот когда они разрослись, то стало совсем плохо, сначала ограничили счетчик количества новых сообщений (условно, 500+), а потом пришлось бэку вообще архитектуру менять

[Void-Cowboy]

всегда лучше закладывать изначально возможность читать батчами для клиента, даже когда кажется что там "всего ничего данных")))

как минимум помогает в таких ситуациях, но вообще спасает и при слабом нестабильном интернете например

в вашей задаче можно было к примеру складывать в inline-json сообщения (как логи пишутся) и тогда ограничения на сообщения вообще нет, вы просто просите с сервера первые 100кб файла например, то есть всегда актуальные данные. Если заполировать etag то латенси на такой "онлайн" будет даже в пределах допустимого))

[vientooscuro]

Всегда лучше закладывать масштабируемость, о чем я говорил ещё в 2020-м, когда только пришел, но меня решили не слушать) С long-polling был в целом валидный аргумент – у ВК так же реализовано. На бэке это упрощает по сравнению с вебсокетами архитектуру, так как http сильно проще, но на клиенте получаем постоянные переподключения, что вообще-то сильно затратно, особенно в условиях 3g-интернета или медленного lte

Но вообще я пока встречал чаты только на websocket (в 4 местах, где я работал), и long-polling в одном. Интересно было бы посмотреть, как делают другие

[Void-Cowboy]

серьезные вещи стараются упаковать в свой протокол, причем зачастую utp плюс легкий tcp. Причем пакуют максимально сжато, бинарно, зачастую даже не протобафами а своей оптимальной под задачу разметкой

фронт-енд же только и только вебсокеты. Видел реализации где пулинг раз в 20сек но там много что было на уровне заголовков, из за чего 90% ответов сервера "холодные" со статусом "без изменений"

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

[akardapolov]

так как http сильно проще, но на клиенте получаем постоянные переподключения, 

HTTP/3 же решает эту проблему (там QUIC который использует UDP)?

чаты только на websocket

Еще есть WebTransport, но пока не очень популярный.

[vientooscuro]

HTTP/3 же решает эту проблему (там QUIC который использует UDP)?

Решает, да, вы правильно заметили, но мы в тот момент поддерживали устройства, у которых поддержки HTTP/3 не было (в iOS 15 появилась), а в Android – не знаю. Также ни я, ни наш CTO, кажется, в подробности HTTP/3 в то время не вдавались, я сам читал только год назад про это, но уже некуда было применять

WebTransport – что-то новое для меня, спасибо большое, изучу!