2014-01-03 2 views
1

Я новичок в node.js/socket.io и, возможно, не спрашиваю об этом правильно или даже задал правильный вопрос.Node.js best socket.io practice (request-response vs broadcast)

Целью моего приложения является получение данных из API, которые преобразуют его в объект JSON и хранят его в mongodb. Затем при необходимости обслуживайте клиентскую сторону данных. Я подумал о двух возможностях и задавался вопросом, какой будет лучшая практика. Мое первое понятие состояло в том, чтобы транслировать все записи в базе данных так часто ко всем соединениям. Другая идея заключалась в том, чтобы иметь клиентский запрос на сервер, какие данные ему нужны, а затем отправить запрошенные данные клиенту.

Данные, хранящиеся в базе данных, составляют около 100 записей. Данные будут обновляться с API примерно каждые 30 секунд. Если выбран метод 1, данные будут транслироваться каждые 5-10 секунд. Если выбран метод 2, данные будут отправляться по запросу. Клиентская сторона будет иметь разные ситуации, когда не все данные будут необходимы все время. Клиентская сторона должна будет запрашивать данные так часто, чтобы убедиться, что данные «свежие».

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

Извините, если это не имеет смысла. Спасибо за ваше время.

+0

Я бы порекомендовал посмотреть на [Метеор] (https://www.meteor.com/) паб/подсистему и их [протокол DDP] (https://github.com/meteor/meteor/blob/ разви/пакеты/livedata/DDP.md). Идея заключается в том, что сервер публикует определенные данные, а затем клиент подписывается на некоторые из этих данных. Сервер отправляет клиенту нужные ему данные, а обновления отправляются только тогда, когда происходят изменения. – sbking

+0

Спасибо за предложение, я проверю его. Вся система кажется немного тяжелой, но реализация протокола DDP очень интересна. – richardnixonthethird

ответ

0

Протокол DDP, безусловно, интересный способ пойти, но это может быть излишним. Упрощенное решение состоит в том, чтобы максимально эффективно использовать оба метода 1 и 2. Если время ожидания не так важно, и у вас есть запасная полоса пропускания, вы можете транслировать сообщение «обновление» всем клиентам, когда появятся новые данные. Клиент считает, влияет ли обновление на него и загружает нужные ему данные.

Чуть более сложный и эффективный подход - процедура подписки, очень похожая на DDP. Для небольших проектов вы можете реализовать это самостоятельно через некоторое время. Вот как это могло бы работать:

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

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

+0

Спасибо за ваш ответ. Я думаю об использовании реализации «комнат», чтобы отличить, какие пользователи получают то, что. Знаете ли вы, что это хороший способ хранения клиентов для получения определенных данных? – richardnixonthethird

+0

Извините, я понятия не имею, в чем состоит реализация помещений. – Strix