Поясните кто нибудь за вебсокеты и лайв чат с историей,

в голове пока такое:

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

В маша идет в школу примерах примерно так и есть. Как оно у взрослых людей без понятия

Взрослые не рассказывают почему то

Чей ID будет? просто соединения сокета, а если он отвалиться он другой потом будет, при обновлении страницы экземпляр класса уничтожается и соединения дисконектиться и будет новый ID. Идентификатор пользователя нужен, отправлять его по сокету и получать ответ. Веб сокеты тема)

Тогда мне как в Маше вариант подойдет больше

Id румы, все комнаты также хранятся в бд, при реквесте открытия сокета буду делать чек румы и чек прав пользователя, если все ок - открываемся, вроде звучит норм, нет?

https://github.com/ezesundayeze/anonymouse-realtime-chat-app ну вот первая ссылка на которую я упал, без авторизации там смотри по своим обстоятельствам

Спасибо, изучу

Я прорабатывал/внедрял на вебсокете решение связанное с телефонией. На мой взгляд важно проработать момент того что могут попытаться стучаться на сокет и изучать "протокол" как бы проще будет. Я бы авторизацию на веб сокете не делал, ну т.е. в плане надо авторизовать/аутентифицировать пользователя обычными методами и решениями, а затем когда он прошел проверку можно пускать на нужный пейдж где поднимается сокет и там еще доп проверка.

А на бекенде лесом слать другие попытки поднятия сокета если сокет не присылает данные авторизации.

Ну в целом так и хотел сделать, авторизация уже есть access + refresh, просто access кидать при открытии и его чекать, то есть если я хочу что-то делать с бд или еще что, делать это в другом месте, сокет чисто для обмена сообщениями, верно?

Зависит от реализации на бекенде. Если грамотный подход то устанавливается соединение клиент-сервер под конкретным ID на бекенде. Чтобы всем не слать мессаги. Получается бекенд знает что вот этот ID принадлежит этому пользователю т.е. какая-то мапа в оперативке или ещё где. Один пользователь может открыть несколько экземпляров соединений (страниц открыть) - вот тут надо серьезно подумать как будет осуществляться синхронизация между соединениями, особенно с учетом если отказоустойчивая кластеризация, балансировщик сети, ноды. Я бы рекомендовал сначала схему со всеми цепочками нарисовать прежде чем ввязаться в историю.

Мы делали как, поднимается соединение и клиент отправлять стартовую мессагу с кое-какими данными условно говорящие серверу мол я такой-то, дай мне текущий статус по мне. Сервер в этот момент понимал что это последнее активное соединение с пользователем и есть гарантия что сообщение от сервера прилетит в правильный сокет и страница перед глазами юзера. Сокет может разрываться хаотично на фоновой вкладке. Чтобы держать его "активным" пинг-понг "системными" мессагами можно держать в тонусе и не разорвалось или перезапускать при разрыве что выглядит дороже для бекенда. Это как бы с чем столкнулись. Шифровать надо, а по факту гоняешь JSON внутри, т.е. что угодно можно засунуть. Мы прям протокол взаимодействия разработали.

Звучит не очень весело, но хотя бы в голове начинает складываться пазл, спасибо

Блин может я жути нагоняю, мы не юзали сторонние либы (ну кроме проксирования вебсокета) на фронте браузерный WebSoket клиент + React+Node.js бекенд java spring boot. Наверное за месяца 2-3 все подняли, что выглядит довольно быстро наверное. Просто очень много кейсов которые на старте надо учитывать - если 1 клиент отвалился с остальными соединениями что, синхронизироваться чем (Kafka, RabbitMQ? и прочее) и т.д. "Живой" фронт реагирующий на веб сокеты это выглядит как магия) я думаю ещё бы заюзал сокеты где-нибудь.

Да нет, в целом ожидал что будет запара, в инете много примеров кода и туториалов поверхностных, а в плане архитектуры и логики особо не нашел, так что такое чтиво это вообще супер

А что если твоё сообщение отправится пост запросом, а сокет провалится? По факту будет добавлено, но текущие пользователи в комнате не увидят его. Можно записывать сообщение в основную БД и уже отформатиованное и готовое в, к примеру, redis, а затем отправить уведомление (pub/sub система), а пользователей подключившихся по сокету подписывать в redis и получать эти самые уведомления и уже отправлять в комнату.

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

Вот он хорошо рассказывает на примере. Вообще, смотрю его давно, чувак молодец. https://youtu.be/gzIcGhJC8hA

Тогда пили на ajax'е, а потом уже перепишешь! Очевидные вещи нужно сразу решать, а не откладывать, а потом волосы на жопе рвать.

Для меня больше половины услышанного было неочевидно, в каких то моментах даже вопрос сформулировать не могу что хочу сделать, так что где то придётся сначала сделать говно, а потом сделать не говно

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

Это просто транспорт, АПИ может быть одно

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

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

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

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

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

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

Тогда на стороне сокета нужен доступ к бд. Вообще, такое масштабировать будет сложно.... Как по мне.

Он с самого начала упомянул, что само сообщение отправляется пост запросом отдельным, а не по сокету. У него, может та часть вообще на другом языке написана и никак с нодой не связана.

А как без БД то? Мы же о приложении говорим. Масштабируется это дело без особых проблем - я и проксирование делал, и через балансировщик работало, и клиенты на разных нодах кластера. Всё это дело прекрасно работает и проде жило лучше чем на деве.

Ну гонять пост запросом наверное в такой случае лишено смысла наверное. Если есть сокет то его и использовать надо - я в обе стороны взаимодействовал никаких проблем особо не заметил. Можно посмотреть как другие крупные сайты делают, Notion по сокету данные гоняет, что-то по rest api.

Предположим ты поднял два сокет сервера, где 10 человек подключены через балансировщик к серверу А, а другие 10 к серверу B. Допустим, что пользователь отправил сообщение на сервер А, как пользователи, которые подключены к серверу B узнают о поступление нового сообщения?

Вполне себе да, можно сразу и по сокету, если стек один и тот же.

Но здесь, скорее всего, свои нюансы могут быть....

Ну сообщение от клиента 1 пришло на бекенд А), то бекенд должен сохранить месседж в базу по нику и переслать что-то клиенту 2 на сервере В). Я писал выше про синхронизацию, что нужна мапа которая организует пользователей кто где на каком сокете. Зависит от возможностей - либо всем стучаться в базу данных и там самостоятельно организовывать синхронизацию, либо использовать платформы гарантированной доставки сообщений - кафка и т.д. Это самое очевидное что в голову приходит.

Интересно, как ты подобное уже ревлизовывал, если у тебя нет точного представления об этом?)

Я как раз реализовывал)

А что за синхронизация? Как именно работает?

Связка такая: react, websoket, hazelcast, mongodb. Бекенд где hazelcast, писал не я - т.к. я фронт)

По сути, все то же самое, что и я описал

А что требовалось услышать)? Расписать 10 000 строчек кода надо было? Где за бекенд конкретно я не отвечал. Прямо сейчас этим проектом я не занимаюсь уже пол года наверное. Прокси писал чтобы сокеты через балансировщик ходили.