Отправка событий от бека к фронту

Лень монтажить вебинар, пока вынесу с него интересный вопрос:

- Если WebSockets, HTTP/2, SSE позволяют слать сообщения с бека на фронт, то почему в основном говорят о WebSockets для двухстороннего взаимодействия?

Server Sent Events
Чтобы получать события с сервера клиент кидает GET-запрос с указанием в заголовках, что хочет сохранить соединение и получать события. Если сервер так умеет, то создается длительное соединение, и он начинает слать сообщения клиенту, пока кто-нибудь соединение не закроет.
Работает SSE поверх HTTP/1.1 и выше.

Позволяет слать события только в одну сторону: сервер —> клиент.
Прост в реализации, не нужно затаскивать в проект новый протокол и тулинг под него, кто-то считает устаревшим.

Если честно, я даже не знаком с людьми, которые использовали SSE. Нашел пару примеров:
⁃ В SuperJob их юзают просто чтобы не заморачиваться, как я понял.
⁃ Тут их используют для реализации subscriptions в GraphQL. Ну ок, есть логика

У вас был такой опыт? Поделитесь в комментах, плз.

HTTP/2
Взаимодействия между клиентам и сервером делятся на стримы. Каждый стрим состоит из одного request-сообщения и одного response-сообщения. Каждое сообщение может состоять из одного и более фреймов.

Причем сервер может начать слать фреймы ответа до того, как получил от клиента все фреймы ответа. Причем количество фреймов неограничено, и я необязан указывать его в первом фрейме сообщений. Такой вот стримминг внутри стрима получается. Внезапно, правда?

Получается, что внутри стрима мы можем слать фреймы в двух направлениях. НО - создать стрим может только клиент. Т.е. парадигма request-response в протоколе сохраняется.

В теории так сделать можно, но разрабы нас за это сожгут, так мы предлагаем ручками лезть в потроха протокола. Так можно и сразу с TCP напрямую работать. Или кто-нибудь знает готовые либы под это?

На практике проще сразу брать gRPC, который использует эту механику. Но это новый стек, новые проблемы.
Либо заюзать те же SSE.

Почитать: Хардкорный разбор HTTP/2

WebSockets
Полнодуплексный протокол, в котором мы устанавливаем соединение, клиент кидает GET запрос с нужными заголовками и вместе с сервером переключается на общение поверх вебсокетов. Клиент и сервер могут в произвольном порядке слать друг другу сообщения, пока кто-нибудь не закроет соединение
Работает поверх TCP.

Позволяет слать события только в обе стороны: сервер <—> клиент.
Сложнее в реализации, чем SSE, т.к. многие не умеют его готовить, нужно затаскивать новый протокол и тулинг в проект.

Почитать: основы вебсокетов, мини книга с погружением.

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

#интеграция