dosya97
@dosya97
Fullstack web-developer

Какая архитектура при проектировани чата лучше?

Не ругайте меня за лишние теги, пожалуйста. Умные и опытные люди слушающие данные теги послужили причиной ))


Привет, это очередной вопрос про real-time chat между пользователями. Но в этот раз вопрос чисто теоретического характера, нежели практического. Как организовать структуру месседжинга базируясь на websockets+ajax? Как я понял, websockets достаточно быстрая и шустрая технология по сравнению с лонгполлингом, так как не нужно перегружать сервер ненужными ожидающими запросами. Поправьте, если у меня не правильно сформировались убеждения))

На клиенте у меня стоит компонент Messenger в нем два блока:
1) Поле чата (Это еще один компонент Chat со своим стейтом и с keep-alive) При инициализации данного компонента осуществляется запрос на REST API. Далее этот компонент рендрит сообщения по полученным данным. Стейт внутри компонента сохранен, теперь нет надобности их подгружать снова. При повторной активации компонента, запрос на сервер не осуществляется.
2) Поле или список с последними переписками. Это тоже отдельный блок и он грузится также отдельно через REST API.

Проблема возникает тогда, когда начинаешь задумываться: "А как же обновлять данные динамически и лаконично?".
Чую, что слушать каналы(Группы) всех связей с пользователями очень глупо. Представьте, что у меня 1000 друзей и со всеми я общаюсь, так если я не один такой. Микросервис django-channels просто обкакается, да что уж django-channels, websocket такого не потянет)))

Пришла идея все делать как в вышесказанном методе, но с помаркой на websockets. Слушать только свой канал, который создается при коннекте на websockets. И когда другой пользователь отправляет сообщение он смотрит открыт ли этот канал, если да то отправить данной группе объект с новыми данными, если нет то нет смысла, если слушателя на другой стороне нет, он может при retrieve данных получить сообщения. Но можно ли узнать открыт ли канал, или нет?

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

Можете подсказать?
  • Вопрос задан
  • 2323 просмотра
Решения вопроса 2
Stalker_RED
@Stalker_RED
Я мало что понял из вашего рассказа. можно сделать все довольно просто:

Клиент открывает соединение с сервером и делает следущее:
1. отправляет свои сообщения (если написал что-то) и действия
2. получает сообщения, которые ему передал сервер. (Адресованные ему в личку, или в тот канал/каналы, которые активны у клиента в данный момент).

Сервер держит соединения со всеми активными клиентами. Получая от них сообщения - рассылает их подписчикам.

Конец.
Ответ написан
1. Вебсокетное соединение node может держать до 1 миллиона, в зависимости от железа и количества серверных нод. На джанго + джанго каналы попечальней, но думаю 1к спокойно вытянет.
2. У вк тоже нет всего списка сразу, а показывают последние 10-15 например.
3. Для диалогов делать по аналогии вк - грузить послдение 10 сообщений, а при скроле догружать еще.
4. По поводу клиента, я так понял он на vue. И вы правильно подумали, что при первой загрузке в стейтах хранитьпоследнее сообщение. Далее по клику на диалог - догружать в ячейку стейта конкретного диалога 10-15 предидущих сообщений. Но мне кажется, если догружать еще сообщения, и сделать это в несколько диалогов, то производительность может падать.
Но вдруг vue так силен. В принципе у вас ход мыслей правильный, при заполнении в стейт сообщеньками будет быстрее работать в кейсе, когда переключаешься между диалогами.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
@Azperin
Дилетант
Вроде как уже давно нода стала синонимом чата. Не вижу там проблем общения 1к человек, вебсокеты точно потянут, откуда обратная инфа даже не представляю.
Вобщем банально почитай документацию https://socket.io/
Ответ написан
@Coder321
Думаю при старте получать список всех каналов и создавать только одно подключение. В то же время с сервера слать название/айди канала и сообщение, на фронте смотреть название/айди и пушить сообщение в нужную комнату. В принципе, сказал все тоже что и Stalker_RED
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы