Что нужно изучить, чтоб написать виджет чат с нуля?

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

Пока идея зависла на ТЗ и на чём писать (я больше склоняюсь к PHP+JavaScript(одна из его вариаций, какую, не знаю.)+ MySQL):

1. Обычный текстовый чат
2. Пользователи заходят через соцсети
3. Должна присутствовать возможность отправки лс по системе p2p т.е. отправка личных сообщений происходит напрямую к пользователю, без сохранения на сервере. Я так понимаю это можно как-то сделать через WebRTC
4. Для разгрузки сервера в голове застряла мысль проработать вопрос отправки сообщения не клиент-сервер-клиенты, а что нибудь посложнее, на пример клиент-сервер-несколько_клиентов-остальные_пользователи, что-то типо террента только для сообщений.
5. Код встраиваемый в сайт должен быть одинаков т.е. я или кто хочет из знакомых, чтоб установили код и он сразу заработал, при этом сообщения с других доменов не пересекались.
6. Как хранить это в базе. держать все сообщения в одной таблице или лучше выбрать что-то другое?
7. Остальную кучу мыслей не могу сформулировать.
Может быть глупые задумки, но для опыта такое мне бы сгодилось.

И спасибо за то, что дочитали, то что я написал.
  • Вопрос задан
  • 2779 просмотров
Решения вопроса 1
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Пройдемся по пунктам:
1) WebSockets
2) Все что касается авторизации не относится конкретно к задаче чатика. Можно конечно замарачиваться, и выносить функционал авторизации в отдельный демон или поток и общаться через Pub/Sub (например ZeroMQ). По сути главное что бы во время верификации пользователя мы могли обрабатывать другие соединения
3) Если вы хотите p2p доставку сообщений с WebRTC, то сервер вам нужен будет только для авторизации и аунтефикации клиентов, ну и что бы клиенты могли найти собеседников. В этом плане серверная часть упрощается и снижаются требования по нагрузкам, но усложняется клиентская часть.
4) К сожалению вы не можете отправлять бродкастом сообщения, так как используется TCP. Можно конечно организовать что-то типа очереди, но я не вижу причин для выйгрыша в производительности. Тут больше вопрос архитектуры и каким образом вы синхронизируете списки пользователей.
5) Ну... тут не вижу проблемы. Если вы хотите иметь один сервер для всех виджетов, то просто добавить поддержку CORS и токены для запросов (в заголовках) что бы разграничивать по доменам.
6) А что именно вам надо хранить в базе? Сообщения у вас на сервере, как вы сказали, не хранятся... Пользователи - любой вариант, тот же MySQL (а лучше PostgreSQL, для которого есть возможность использовать асинхронные запросы в базу, что бы было интереснее). Текущих пользователей и прочее можно хранить в Reddis и т.д. Главное что бы хранилище было быстрым.

Вообще задумка интересная, вариантов реализации масса. Это можно спокойно и на PHP написать, есть ReactPHP + Ratchet для организации сети пользователей, а для доставки сообщений вы и так хотите использовать WebRTC. Просто на сервере в супервизор надо поставить парочку демонов (по одному на ядро) и сверху поставить nginx, который будет балансировщиком и проксей. Учитывая что вы нехило можете за счет WebRTC и каких-нибудь архитектурных трюков уменьшить итоговую нагрузку на сервер, проблем с производительностью быть не должно. Так же для ReactPHP было бы неплохо поставить libev/libeven, словом там по документации можно пройтись и почитать что да как.

Update:
отстал я от жизни, как раз таки UDP можно использовать в браузерах (во всяком случае в последних билдах хрома), в частности для передачи информации между браузерами (а не аудио и видио) можно использовать datachannels. Так что тут все упирается в то, как доставлять сообщения между клиентами. Остальное уже зависит от того, как вы все же решите все делать.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Если модно, то с помощью nodeJS. Решение шустрое, пых отдыхает, к то му же чат без тормозов, как говорится, в прямом эфире. Устойчив к нагрузкам.
Ответ написан
Комментировать
@Calc
Посмотрите в сторону WebSockets
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы