Server Sent Events

• Server Sent Events
  • Зачем
  • Плюсы-минусы
  • Модель
  • Patterns
  • Технологии

Зачем

Реализует однонаправленную связь в паттернах интеграции.

Server Sent Events (Server-Side Events):

• Соединение постоянное, протокол HTTP, альтернатива Polling, Long Polling from FrontEnd
  • Long-Polling with XHR
  • vs websocket
• скорость, равная скорости потоковой передачи в формате JSON
• меньше накладных расходов на установление соединений vs Polling
• Прост в реализации и использовании, как на стороне клиента, так и на стороне сервера, более производителен для сервера, меньше задержка ответа клиента vs Long Polling
• Безопасность
  • на уровне клиента по Origin от кого сообщения
  • на уровне сервера CORS with сredentials in Headers API Key (аналогично с fetch)
• built-in support for reestablishing dropped connections, as well as recovery of messages the client may have missed while disconnected.
  • By default, if the connection is dropped, then the browser will automatically reestablish the connection. The SSE specification recommends a 2–3 second delay, which is a common default for most browsers, but the server can also set a custom interval at any point by sending a retry command to the client.
• Sending Comment

Плюсы-минусы

Плюсы:

• automatic reconnection,
• event IDs
• automatic event parsing

Минусы:

• Ограничение, связанное с количеством соединений, которые могут быть открыты между клиентом и сервером одновременно
• Поддержка 97,5% браузеров в 2023 году, но IE<11 нет, Edge только
• It only allows data reception from the server (unidirectional)
• Events are limited to UTF-8 (no binary data)
• Limitations on connecting from one browser at a time:
  • HTTP/1.1: Max 6-8 connections at a time.
  • HTTP/2: Max 100 connections by default (can be changed from server configuration).

Модель

Модель:

• data - JSON
• event - Event Name - Client subscribe to type of events
  • default генерирует 3 события:
    • message – получено сообщение, доступно как event.data.
    • open – соединение открыто.
    • error – не удалось установить соединение, например, сервер вернул статус 500
• lastEventId - ИД события
• retry - мс на переподключение при обрыве связи

Patterns

• Адресация сообщений возможна по event
  • пример: ИДПользователя_ДоговорСтатусИзменен, где клиент подписывается на события для конкретного пользователя, сервер ИД пользователя получает при аутентификации.
• Обработка потери соединения
  • Setting an ID lets the browser keep track of the last event fired so that if, the connection to the server is dropped, a special HTTP header (Last-Event-ID) is set with the new request. This lets the browser determine which event is appropriate to fire. The message event contains a e.lastEventId property. server can implement several different strategies:
  • If lost messages are acceptable, then no event IDs or special logic is required: simply let the client reconnect and resume the stream.
  • If message recovery is required, then the server needs to specify IDs for relevant events, such that the client can report the last seen ID when reconnecting.
  • Also, the server needs to implement some form of a local cache to recover and retransmit missed messages to the client. . - варианты реализации на сервере получить сообщения после last-event-id: Redis Streams

Технологии

• signal.ir
• Node.js
• PHP
  • MDN sample
  • PHP
  • YII2
• vue plugin
• Node JS example
  • server docker example
• .NET
• Fetch API
  • support SSE format message
  • более гибкий вариант (Body & Headers parameters, HTTP Method не только GET, больше вариантов обработки сбоя соединения)
  • fetch() function
  • support disable events on browser minimize Page Visibility API