SSEGWSW: Server-Sent Events Gateway by Service Workers

[ddidwyll]

Спасибо, очевидное и простое решение. Сейчас в разработке проект с аналогичной схемой клиент-серверного общения, надо будет использовать ваш подход.

[Shoom3301]

Обязательно реализуйте механизм закрытия потоков, они блокируют активацию новой версии service worker. Помимо того, чтобы закрывать поток при закрытии вкладки я еще сделал закрытие всех потоков через интервал.

[2tl]

при обновлении конфига NGINX рвались все соединения, которые потом больно было восстанавливать

Я правильно понимаю, что SSE соединение тоже порвется при обновлении конфига?
Поясните, пожалуйста, про разницу в восстановлении соединений для SSE и WebSocket

[2tl]

Нашел неплохую статью с подробным сравнением технологий: www.smashingmagazine.com/2018/02/sse-websockets-data-flow-http2

If the connection drops, the EventSource fires an error event and automatically tries to reconnect. The server can also control the timeout before the client tries to reconnect (explained in more details later).

[Shoom3301]

Честно говоря, я не знаю деталей реализации на бэкенде. Поинтересовался у коллеги и он ответил:

Потому что инициализируется начальное состояние фронта
Лезем в бд и т.д.

[monochromer]

Service Worker может засыпать после некоторого времени бездействия. Как-то решали такую проблему?

[t0rr]

А что плохого в засыпаниях?

Пользователь неактивен - пусть воркер спит. Когда SSE на стороне клиента перестанет вычитывать `: ping` от сервера, сервер может спокойно разорвать соединение.

Когда пользователь станет активным и Service Worker проснётся, он увидит разорванный стейт и пойдёт переподключаться. Если вы передаёте id в отправляемых сообщениях, то при переподключении SSE передаст идентификатор последнего полученного в заголовке "Last-Event-Id" - дальше у бэка есть всё для принятия решения (отдавать пропущенные или нет).

[alxgrn]

А как у вас делается авторизация пользователей при таком подходе?