Можно ли использовать Node.js в качестве маршрутизатора?
Собственно вопрос такой, интересует мнение спецов касательно, того что бы использовать Node.js в качестве маршрутизатора, которые обновляет данные в реал тайме.
Тоесть:
К примеру есть ситуация когда нужно в реалтайме обновлять данные и собственно идея такая:
Мы открываем сокет и передаем данные
например php по сокету обращается к node.js и говорит дай мне данные из базы вот этого юзера,
node.js обращается к другому пхп скрипту (так как драйвера нода для mysql) получает данные
и отдает их обратно.
Как поведет себя такой метод при большом кол-во запросов?
Хаотично описана задача, опишите точнее, и желательно без предположений, как это можно сделать, а просто что нужно сделать, тогда можно будет посоветовать.
1. Зачем вам серединка в виде node.js? Почему два пхп скрипта не могут сами между собой работать?
2. Присоединюсь к @dizballanze - что с драйвером mysql в ноде не так? Для чего нужно ещё куда-то подключаться?
3. Я так понял, это реалтайм на стороне бэкенда. А что в таком случае является триггером для обновления? А триггер может сработать сразу в node.js, а не тянуть всю эту цепочку?
1)На странице есть список заявок для игр. Нужно в реал тайме обновлять данные. Сейчас стоит SSE и возвращается JSON вида:
id заявки, пользователи в заявки, время создания
и js бегает по таблице и обновляет заявки.
Проблема такая, я использую Yii и когда идет запрос пхп честно отдает данные и умирает. И каждый последующий запрос постоянно открывает, закрывает соединения. JS библиотека EventSource постоянно выкидывает событие error.
Почему node.js ну он может держать постоянное соединение с сокетом и достаточно жирный в плане нагрузок
2) Виноват информация лично мной не проверена, слухи
3) В общем логично ли тогда будет сделать вот так:
Страница всех заявок и конкретной заявки
Необходимо обновлять данные: какие пользователи в заявке, дата ее создания
php рендерит страницу и подключает сокет
node.js пасет сокет и отдает данные из базы. (тут нужен join для реляции)
и отдает все это дело клиенту где js рисует
Попытаюсь ответить на последнее и предложить своё решение.
1. Хорошо, если рендер может быть выполнен на стороне сервера, но такое достигается не всегда. В данном случае вы притягиваете фронт для вебсокетов в виде php для рендера? Это плохой вариант. По каналу сокетов должен возвращаться diff для модели, не для отображения.
2. Я по-прежнему не увидел ответа на вопрос - что является триггером для сообщения со стороны сервера? Грубо говоря, как сервер узнает, что в бд появилось что-то ещё (или изменилось)? Я не вижу иного способа, кроме как сказать об этом php-server-side to socket-server-side.
3. Продолжая предыдущий пункт. Вы представляете себе, каким образом нужно связать постоянное соединение (сокет) с временным (запрос к php)? Я - не представляю. Посему как альтернативу я предлагаю MQ. Более того, mq сам может быть сервер-сайдом для вебсокета.
Резюмируя:
Через yii у вас возвращается первоначальная страница. На странице js подключается сокетом к activemq серверу (stomp, mqtt - это по вкусу). Параллельно yii принимает другие запросы (на создание, изменение) и соответствующие diff чанки шлёт в mq. Из MQ они естесно попадают в js клиента. На клиенте на основе diff уже изменяете html как вам угодно
Простой
