Отправленные сервером события (SSE): концептуальное глубокое погружение

Почему вы используете SSE?

В идеале, при запросе данных с сервера, просто XMLHttpRequestподойдет. Однако существуют сценарии, в которых вы хотите сохранить соединение открытым с использованием потоковой передачи XHR. Но это приносит свой собственный набор издержек, включая обработку логики синтаксического анализа и управление соединением.

Вот тут-то и приходит SSE. SSE обеспечивает уровень логики управления соединением и синтаксического анализа, что позволяет нам легко сохранять соединение открытым, пока сервер передает новые события клиенту по мере их появления.

Когда бы вы использовали SSE?

Природа обмена сообщениями в реальном времени и потоковых данных означает, что разные протоколы служат различным целям лучше, чем другие. Для мультиплексной, двунаправленной потоковой передачи WebSockets идеально подходит. Для устройств IoT с ограниченным временем автономной работы MQTT больше подходит. Но иногда это излишне.

SSE идеально подходит для таких сценариев, как:

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

Вот несколько примеров, когда SSE уже используется:

• Подписка на канал криптовалюты или цены на акции
• Подписка на канал Twitter
• Получение живых спортивных результатов
• Новости обновления или оповещения

Что нужно учитывать в SSE

Как и во всем, у SSE есть свои проблемы.

Основным ограничением SSE является то, что он является однонаправленным, поэтому нет возможности передавать информацию на сервер от клиента. Единственный способ передать дополнительную информацию во время соединения, что многие разработчики предпочитают делать со строками запроса. Например, если указан URL-адрес потока http://example.com/sse, разработчики могут добавить строку запроса для передачи такой информации, как идентификатор пользователя http://example.com/sse?userid=891.

Эта однонаправленность вызывает дополнительную проблему: когда клиент теряет соединение, нет надежного способа сообщить серверу, как нет способа выполнить тактовые импульсы от клиента к серверу. Поскольку SSE основан на TCP / IP, существует механизм, который предупреждает сервер, когда клиент теряет соединение. Но это не всегда работает хорошо, поэтому сервер не всегда сразу понимает, что соединение потеряно. Однако это незначительное ограничение для SSE.

Поддержка SSE

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

Браузеры, которые поддерживают SSE по состоянию на июнь 2019 года.

Стоит также проверить EventSourceподдержку. Смотрите пример ниже, используя polyfill:

if ('EventSource' in window) {
  // use polyfills
}
var source = new EventSource('URL');

res.write('data: {\n');
res.write('data: "foo": "bar",\n');
res.write('data: "baz", 555\n');
res.write('data: }\n\n');

app.get('/stream', (req, res)=>{
  res.status(200).set({
    "connection": "keep-alive",
    "content-type": "text/event-stream"
  });
  res.write(`data: Hello there \n\n`);
});

var SSE = require('express-sse');
var sse = new SSE();
app.get('/stream', sse.init);
// we can always now call sse.send from anywhere the sse variable is available, and see the result in our stream.
let content = 'Test data at ' + JSON.stringify(Date.now());
sse.send(content);