Когда стоит сменить REST на web socket?

Question

[hbrmdc]

Веб-приложение на ReactJS, nodejs+express сервер, бд PostgresSQL.
Сейчас все на REST. В основном - запросы данных при загрузке страниц (1-2 запроса на каждую страницу), но также есть несколько часто используемых полей ввода с динамическим автодополнением (то есть на каждый keyup происходит rest запрос в бд, чтобы найти подходящие варианты). Кроме того, есть не слишком важная система уведомлений. Real-time приход уведомлений не слишком важен, но лишним не будет.
Единственно важный функционал, который, как я думаю, напрасно сделан на REST вместо веб-сокета - это синхронизация данных пользователя. Дело в том, что пользователь может редактировать множество общих объектов в веб-приложении, и в некоторых случаях отредактированный объект может повлиять на данные пользователя, то есть их приходится запрашивать периодически из бд.
Хорошо ориентируюсь в REST, еще не работал с socket.io.

Собственно, вопрос:
Если перевести все общение с сервером на Socket.io, как это отразится на загруженность сервера?

Благодарю, за уделенное время!

Comments

[StrangeAttractor]

Я, вот, только собираюсь сейчас сесть и начать изучать WebSockets на деле (в общих чертах, конечно, представление имею, но очень-очень абстрактное, так что, возможно, скажу глупость), но у меня сразу возникает обратный вопрос: а зачем (кроме как, может, ради совместимости с какими-то древними браузерами) вообще использовать для передачи данных между клиентской и серверной частью приложения обычный HTTP когда есть WS? Почему бы не писать сразу с WS и только с ними?

[Александр Таратин]

StrangeAttractor:
1. В php потому что не завезли способа работать с WebSockets так чтобы на хостингах ехало.
2. Не всем нужно постоянно держать открытое соединение.
3. Для перессылки только в сторону клиента есть caniuse.com/#feat=eventsource только в ie его похоже никогда не будет.

Answer 1

[Александр Таратин]

то есть на каждый keyup происходит rest запрос в бд

Немного не в тему, но можно делать так
jsfiddle.net/3m9593o2

spoiler

function Detour(cb, time) {
  this.cb = cb;
  this.interval = 0;
  this.time = time;
}
Detour.prototype.runNow = function(){
	clearTimeout(this.interval);
  this.cb.apply(null, arguments);
}
Detour.prototype.run = function() {
  clearTimeout(this.interval);
  var args = arguments;
  var cb = this.cb;
  this.interval = setTimeout(function(){
  	cb.apply(null, args);
  }, this.time);
}

var testCallback = new Detour(function(inputElement){
	console.log(inputElement.value);
},200);

$('#itarget').on('input change keyup', function(){
	testCallback.run(this);
})

Comments

[hbrmdc]

благодарю, полезный совет

Answer 2

[Владимир Чернышев]

В общем случае при грамотной реализации снизится, так как клиенты не будут запрашивать сервер "а не изменилось ли что?".

Answer 3

[Александр Вульф]

Переведете все на сокеты, потом смените БД на mongo и получите meteor! :)

Comments

[hbrmdc]

Насколько мне известно, mongo - это nosql, следовательно область применения довольно специфична, и переход на нее с sql субд мало вероятен.

[Александр Вульф]

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

[hbrmdc]

делаю выводы на основе вот этой статьи: habrahabr.ru/post/231213

[Александр Вульф]

hbrmdc: очень провакационная статья. Да и девушка (автор) не разобравшись в noSQL пишет ересь. Звучит это приблизительно как: «Я ем 3-4 раза в день, последний раз я ела суп вилкой, никому не рекомендую пользоваться вилками!» :)

[Александр Вульф]

hbrmdc: ах, и статья датируется 2010(!) годом. С того момента прошло уже 5(!) лет. Монго стала в стотыщраз круче.

[hbrmdc]

ну у меня сходная ситуация - я ем именно суп) У меня почти все типы объектов имеют связи с другими типами объектов. Дублировать инфу в каждом документе просто нет смысла с учетом частых мелких изменений.
Простейший пример: комментарий, у комментария есть текст и есть связь с пользователем, создавшим комментарий, чтобы можно было сформировать ссылку на страницу пользователя прямо из его комментария. У пользователя есть переменные, которые отображаются в каждом комменте - аватар и имя. Следовательно, мне нужно либо создавать связь с пользователем, либо копировать необходимые данные в каждый документ комментария.
То есть, мне нужна реляционность. К тому же, postgres (кажется с версии 9.4) также работает с json объектами, то есть у него есть и преимущества документо-ориентированой бд и реляционной. Если я не правильно это понимаю, пожалуйста, дайте ссылку на подходящую статью/видео на эту тему. Можно на английском.

[Александр Вульф]

hbrmdc: загляните в эту статью (она как ответ к той, что прислали вы): habrahabr.ru/post/243431

[hbrmdc]

Не убедительно, все доводы, которые я привел бы вам в пользу postgres приведены в комментариях. В любом случае, благодарю вас за предоставление альтернативной точки зрения!