@paulvales

WebSockets или setInterval?

Здравствуйте,пишу CRM на обычном PHP. Есть страница с заказами ,каким образом можно сделать оповещения без обновления страницы?
Заказы подключаются через AJAX:
function vse() {
      var msg   = $('#formx').serialize();
    
	  $('#conn').addClass('progress');
      $.ajax({      
          type: 'POST',
          url: '/a/vse.php',
          data: msg,
success:  function(data) {

            $('#conn').html(data);
          },
		  complete: function() {
        // деактивация индикатора
        $('#conn').removeClass('progress');
    },
          error:  function(xhr, str){
                alert('Возникла ошибка: ' + xhr.responseCode);
            }
       
        }) ;
 
    }
  • Вопрос задан
  • 842 просмотра
Пригласить эксперта
Ответы на вопрос 2
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Тут забавная штука, в вашем примере вы инициализируете опрос сервера. В случае с websockets (или long-polling) сервер уведомляет о том что что-то произошло.

В чем разница? Да в том как сервер узнает что произошло.

Обычно это делают следующим образом:
отдельный сприпт слушает шину данных (zeromq, rabbitmq, redis) и через эту шину пробрасываются события о том что что-то случилось.

Далее скрипт, к которому вы подключаетесь по long-polling или websockets ловит событие из шины данных и отправлят данные на нужный клиент.

C web-sockets в этом случае у вас один процесс-демон (или не один, но это вопрос масштабирования и шардирования соединений) который висит себе и просто в циклике отправляет нотификации. А поскольку оно занимается только форвардингом ивентов на клиент, его можно спокойно написать на ноде (проще потому что есть готовые решения).

С long-pooling на каждое соединение поднимается короткоживущий скрипт (живет он по 10-30 секунд) который, если ничего не произошло, просто умирает, а если все ж произошло, отправляет данные на клиент и.... умирает. А клиент после каждого разрыва соединения устанавливает его заново.

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

В вашем же случае никаких сложностей нет, вы посылаете запрос на сервак и получаете что произошло с последнего опроса. Это наиболее простой вариант реализации но и по ресурсам он наиболее жирный. Ну и есть определенный делей по доставке нотификаций.
Ответ написан
riky
@riky
Laravel
С учетом того что функционалом будут пользоваться буквально несколько человек и то что не сильно принципиально выдавать оповещение секунда в секунду, как например в онлайн чате, то можно забить на long-pooling и web-sockets и делать самый простой вариант - запросы по таймауту раз в 30-60сек.

web-sockets слишком усложнит архитектуру. long-pooling создаст большую нагрузку, так как вы будете в цикле проверять базу, его есть смысл применять если не допускается задержка более 5-10сек. но для заказов мне кажется полминуты-минута не принципиально.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы