Чат в тяжелом проекте на symfony (в любом тяжелом бэкенд-движке) — как?
Есть большой преимущественно контентный проект на любом тяжелом бэкенд-движке (symfony, RoR, Django и т.п.). Для определенности, пусть это будет symfony (стек РНР+Mysql+Nginx).
Задача: сделать в одном из подразделов сайта чат. Насколько я понимаю, для этих задач хорошо подходит Node.Js. С Node.JS я знаком плохо.
Вопросы:
1. Оправдано ли использование этих двух технологий одновременно в одном проекте?
2. Разумно ли выглядит идея делать сервер чата на РНР+symfony?
3. Если использовать Node.JS как сервер чата, то как реализовать одновременную аутентификацию пользователей в РHP-части проекта и Node.JS-части?
4. MySQL — разумно ли его использовать как СУБД для чат-сообщений? Или лучше что-то другое? Если другое, то как связать его с имеющейся базой в MySQL?
1. Да
2. Нет. Если Вам нужен качественный, быстрый, и лёгкий чат. И «Да», если вам не важны эти характеристики.
3. Я бы порекомендовал 2 фазную авторизацию. Когда на чат сервере — своя сессия. И он у симфонии (или наоборот) через RPC подвязывается сессия к пользователю.
4. Лучше сообщения держать в памяти чат сервера. Если вам нужны логи, или модэрация — то сообщения можно выгружать в Мускуль. Но читать их от туда (кроме случая с стартом чат сервера) смысла нет совершенно.
P.S. Примеров чат серверов и на longPooling, и на webSocket на node.js много. RPC реализаций — тоже. Прикрутить чат — дело пары часов (Вместе с кроссаутентификацией итп)
3. Я бы порекомендовал 2 фазную авторизацию. Когда на чат сервере — своя сессия. И он у симфонии (или наоборот) через RPC подвязывается сессия к пользователю.
Интересный подход. Какие у него преимущества перед использованием одной сессии на двоих?
Их на самом деле много. Перечислю несколько.
1. Чат сервер может стоять как угодно далеко, иметь другой домен итп.
2. Чат сервис может использоваться как отдельная компонента от проэкта, шарится между несколькими итп.
3. Нет зависимости от механизма поддержки сессий другого сервиса (представьте себе забытую вкладку с чатом на месяц).
4. Распределение нагрузки и точек отказа.
…
я перечислил несколько — но легко написать более сотни плюсов ( с минусами у меня фантазия(или опыт) хуже)
Выглядит действительно удобнее, но насколько это сложнее в реализации? По идее нужно ведь как-то синхронизировать эти сессии (открывать, закрывать, связывать друг с другом), а это как мне кажется, сильно сложнее, чем просто использовать единое хранилище сессий.
4. Лучше сообщения держать в памяти чат сервера. Если вам нужны логи, или модэрация — то сообщения можно выгружать в Мускуль. Но читать их от туда (кроме случая с стартом чат сервера) смысла нет совершенно.
Правильно я понимаю, что если держать сообщения в памяти сервера чата, то надо их периодически (или постоянно?) записывать их в Мускуль?
Допустим, в чате нужна информация о пользователе uid, nick, roomlist.
В симфони, где вам нужно активировать чат вы делаете RPC вызов ноды createChatter( randomStr, uid, nick, roomlist ) (естественно вызов делаете с авторизацией, к примеру по общему с нодой паролю). Сохранили andomStr в сессии симфонии (если еще раз нужно открывать сей чат). И послали пользователя на your-chat.com/auth/$randomStr. В ноде уже есть ассоциация randomstr -> {uid, nick, roomlist}. Всё. Подобрать/взломать почти невозможно (ведь RPC прошел на прямую без участия пользователя). Синхронизировать ничего не нужно. Просто при повторном вызове createChatter с тем-же uid, старая ассоциация разваливается. Остается только новая.
Записывать в базу сообщения не обязательно (они ведь, должны висеть в пямяти nodejs). Но если хотите можно сбрасывать. Мы, к примеру сбрасывали, все новые сообщения в табличку для лога. А moderation-tool, написанный на PHP говорил чату какие сообщения выбросить через RPC. (Чат у нас написан на perl, но нода даже лучше).
Пока я писал этот текст — я бы успел бы написать websocket-чат с такой аутентификацией ;)
1) Node.js идеально подходит для подобных целей, так что я считаю что оправдано. Тем более что готовых реализаций полно.
2) Все зависит от загрузки. Что бы сделать нормальный чат, вам придется писать его с применением websokets или long-pooling. в любом случае выйгрыш не на стороне php. Только если применять всякие экстеншены для распаралеливания, писать демон и т.д. Намного проще поднять сервер на Node.js (даже с учетом что вы не так сильны в этом). Да и написать надежный сервер на PHP это то еще приключение.
3) stackoverflow.com/questions/5741792/node-js-chat-user-authentication
4) опять же проблем особо нету. Правда все зависит от реализации.
1. Почему бы и нет
2. Смотря что за чат. Если нагрузка не большая, на обычных ajax-запросах/long-pooling
3. В симфони сессии хранятся где угодно, по умолчанию в файлах. Домен один — кука одна. Осталось продублировать механизм их получения.
4. Тут я вам ничего особо не подскажу, но мне кажется если на сообщения не вешать индекс, а только внешние ключи на отправителя/получателя — все будет ок
Я с нодой работал, и чат писал и начал небольшой проектик. По сути express чем-то похож на php-микро-фреймворки, так что разобраться там просто, главное понять что приложение не умирает, как в случае с php(ну или не должно умирать)
А как я и написал выше — смотря что за чат. Если нужен чат для общения сотрудников компании, что-то переферийное — очередь на редисе сделать и вообще не париться.
Если это одна из основных частей приложения — брать ноду
Для организации чатов и других видов push уведомлений лучше использовать комет сервер.
Вы можете поставить себе вот сравнение cometdaily.com/maturity.html
Или можете воспользоватся Saas решениями
Простой
