Тут забавная штука, в вашем примере вы инициализируете опрос сервера. В случае с websockets (или long-polling) сервер уведомляет о том что что-то произошло.
В чем разница? Да в том как сервер узнает что произошло.
Обычно это делают следующим образом:
отдельный сприпт слушает шину данных (zeromq, rabbitmq, redis) и через эту шину пробрасываются события о том что что-то случилось.
Далее скрипт, к которому вы подключаетесь по long-polling или websockets ловит событие из шины данных и отправлят данные на нужный клиент.
C web-sockets в этом случае у вас один процесс-демон (или не один, но это вопрос масштабирования и шардирования соединений) который висит себе и просто в циклике отправляет нотификации. А поскольку оно занимается только форвардингом ивентов на клиент, его можно спокойно написать на ноде (проще потому что есть готовые решения).
С long-pooling на каждое соединение поднимается короткоживущий скрипт (живет он по 10-30 секунд) который, если ничего не произошло, просто умирает, а если все ж произошло, отправляет данные на клиент и.... умирает. А клиент после каждого разрыва соединения устанавливает его заново.
Собственно под оба этих подхода, при наличии очереди сообщений между вашим приложением и штукой которая будет заниматься нотификациями, есть популярные решения вроде того же socket.io.
В вашем же случае никаких сложностей нет, вы посылаете запрос на сервак и получаете что произошло с последнего опроса. Это наиболее простой вариант реализации но и по ресурсам он наиболее жирный. Ну и есть определенный делей по доставке нотификаций.
