Каков наилучший способ создания приложений реального времени с использованием Angular.js и Node.js?

Я новичок в Angular.js и Node.js, но я понял, что есть два возможных способа сделать приложения реального времени. Первый использует Socket.io, а другой использует RESTful с функцией setInterval() в качестве клиентского решения. Я построил свое приложение, используя обе альтернативы, но я не знаю, почему лучше использовать его вместо другого.

Мой контроллер с использованием Angular.js(вариант Socket.io):

function MyController($scope, socket) {

  socket.on('test', function(data){
    $scope.data = data;
    console.log($scope.data);
  });

}

Мой контроллер с использованием Angular.js(альтернатива RESTful):

function MyController($scope, $http) {

  setInterval(function() {
    $http.get('/test.json')
         .success(function(data, status, headers, config) {
           $scope.data = data;
           console.log($scope.data);
         });
  }, 1000);

}

Каковы были бы различия между этими способами? Спасибо заранее!

Ответ 1

Если вы хотите полностью использовать веб-приложение в реальном времени, то сокеты - это путь. Socket.io или SockJS - оба очень хорошие клиенты. Они могут деградировать изящно, когда веб-сокеты не поддерживаются, однако вы можете выбрать способ транспортировки, который вы хотели бы использовать.

Вам нужно будет создать службу подписки на данные для изменений, которые будут распространяться между всеми пользователями. Tower.js и Meteor используют реактивный подход, и они используют прослушиватели событий при изменении модели. В зависимости от того, насколько сложным или насколько мощным вы хотите эту функцию, они будут доступны в разных вариантах.

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

Ответ 2

Основываясь на вашем примере использования, я думаю, что Socket.IO - это путь. Однако есть несколько предостережений для использования WebSockets с Angular. Я рекомендую вам взглянуть на сообщение в блоге, которое я написал на эту тему некоторое время назад: http://briantford.com/blog/angular-socket-io.html

Ответ 3

Нам пришлось выбирать из альтернативы между толкателем (используя Websocket) и Pubnub, который использует Ajax для публикации/подписания событий реального времени. Ваша альтернатива Angular RESTful недостаточно, когда вы пытаетесь общаться в реальном времени между разными пользователями приложения. Например, у вас есть приложение для управления проектами, используемое командой. Один член команды может добавлять/обновлять задачу, в то время как другой может смотреть одновременно. Обновление должно быть опубликовано, и все остальные пользователи, которые в настоящее время вошли в систему, будут подписаны на измененное событие и могут быть уведомлены.

Мы использовали Pubnub, и он работает очень быстро, хотя технология Pusher лучше, но не поддерживается всеми браузерами в настоящее время.

Я знаю, что вопрос касается AJ и NodeJS, но я чувствую, что использование стороннего API подписки/публикации упрощает управление, потому что вам не придется управлять сервером nodejs и большей загрузкой (когда ваше приложение будет популярным). Pusher/Pubnub является масштабируемым, и вы можете масштабировать приложение настолько, насколько хотите.

Ответ 4

Лучше использовать Socket.io в вашем случае.

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

Использование сокета уменьшит работу как на стороне клиента, так и на стороне клиента, а также упростит управление вашими событиями на основе событий.

Ответ 5

Socket.io имеет следующие преимущества:

  • менее ненужный трафик и рендеринг
  • более низкая латентность
  • (возможно) более чистый код

REST имеет следующие преимущества:

  • Поддерживается во всех браузерах и клиентах
  • Меньше открытых подключений
  • Работает лучше в кластерных, проксированных и других сложных сетевых топологиях

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