Уведомления, SSE, SocketIO и Push API

Сравнение и краткое руководство по взаимодействию сервера с клиентом.

API уведомлений позволяет вам использовать встроенные уведомления вашего клиента, поэтому им не нужно просматривать вашу веб-страницу, чтобы получить уведомление. Это чисто функция пользовательского интерфейса.

События на стороне сервера, веб-сокеты и Push API позволяют серверу отправлять данные клиенту (без необходимости инициировать запрос клиента).



API уведомлений, SSE, SocketIO и Push API: Abaganon
Настройте уведомления, события на стороне сервера, веб-сокеты (SocketIO) и Push API с помощью этого быстрого и простого руководства . abaganon.com



Это краткое руководство покажет базовую настройку и использование этих 4 технологий.

Полнофункциональные примеры можно найти по адресу: https://github.com/efossas/WebServerAlerts-POC. Это проверенный концептуальный проект по изучению плюсов и минусов каждой технологии. В этом руководстве я буду использовать модифицированные версии этого кода для обучения. Не все они работают, если вы просто скопируете и вставите.

Кроме того, все мои примеры будут использовать NodeJS на стороне сервера.

О чем идет речь в этом руководстве

  1. Уведомление API
  2. События на стороне сервера
  3. Веб-сокеты с SocketIO
  4. Push API

Что вам понадобится для этого руководства

Ничего такого. Браузер, я полагаю, и Docker, если вы хотите развернуть POC в репо, упомянутом выше.

Уведомление API

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

IE, Mobile Safari и Android не поддерживают его.

На Mac уведомления отображаются в правом верхнем углу. Они могут содержать небольшое изображение и немного текста. Уведомление в POC выглядит так:

Прежде чем вы сможете использовать API уведомлений, вы должны спросить у пользователя разрешение, которое выдаст ему приглашение, которое выглядит следующим образом:

JavaScript для создания уведомлений и запроса доступа выглядит так:

События на стороне сервера (SSE)

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

IE и Edge не поддерживают его.

Настроить SSE на клиенте очень просто. Вы просто делаете запрос на путь к серверу, который запустит SSE и начнет прослушивать сообщения с сервера.

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

Фактическое событие выглядит довольно просто (похоже на протокол HTTP). Каждая строка начинается с id (просто идентификатора события), data (данные, которые вы хотите отправить) или повтора (если соединение с сервером разорвано, количество миллисекунд, пока клиент пытается повторно подключиться) вместе с некоторыми данными. Новая пустая строка означает конец события.

id: 12345 
retry: 3000 
data: put some data here 
data: and some more data here

Ниже приведен пример того, как может выглядеть функция маршрута ExpressJS для SSE:

Веб-сокеты с SocketIO

Веб-сокеты предназначены для двусторонней связи между серверами и клиентами. Хотя их нелегко настроить без библиотеки, существуют библиотеки, которые делают установку невероятно простой. Кроме того, у большинства этих библиотек есть откат к опросу AJAX, когда веб-сокеты недоступны. Поэтому мы будем использовать SocketIO для настройки веб-сокетов.

Веб-сокеты совместимы со всеми современными браузерами.

Настроить веб-сокеты на клиенте так же просто, как и SSE. Если использовать значения по умолчанию, это еще проще. Помимо подключения и прослушивания событий, сокеты также могут отправлять события на сервер с помощью функции emit ().

SSE был настолько прост, что мы записали фактические байты строки в поток ответа. WS немного сложнее. Фактически, он даже использует свой собственный префикс протокола, ws: // (незашифрованный) и wss: // (зашифрованный ssl). Однако SocketIO абстрагирует все это от нас и даже управляет жизнями наших подключений, поэтому нам не нужно. Таким образом, настроить его на сервере довольно просто. Вот пример:

Push API

Push API позволяет серверам отправлять данные клиентам, даже если у клиента не открыта ваша веб-страница или даже браузер. Следовательно, его необходимо использовать с Service Workers (это скрипты, которые всегда выполняются для вашей веб-страницы, даже когда она закрыта) и API уведомлений. Он также работает только через HTTPS и требует использования ключей VAPID для безопасности. При этом заставить его работать определенно непросто, но поехали ...

IE, Safari и Mobile Safari не поддерживают его.

Вот как должны выглядеть шаги по настройке Push-уведомлений на стороне клиента:

  1. Зарегистрируйте сервис-воркер (который прослушивает push-уведомления).
  2. После регистрации сервисного работника проверьте, существует ли уже подписка.
  3. Если этого не произошло, получите открытый ключ VAPID сервера.
  4. Получив открытый ключ VAPID, используйте его для создания подписки с помощью pushManager.
  5. Теперь отправьте информацию о подписке на сервер, чтобы он мог использовать ее для отправки push-уведомлений.

Между прочим, открытый ключ VAPID используется для проверки того, что он получает push-уведомления, на которые он подписан (или, другими словами, push-уведомления могут поступать с любого сервера, имеющего закрытый ключ VAPID).

Вот пример кода на стороне клиента:

А вот как должен выглядеть сервис-воркер:

Вот как должны выглядеть шаги по настройке Push-уведомлений на стороне сервера:

  1. Создайте публичные и частные ключи VAPID.
  2. Создайте http-маршрут, по которому клиенты могут получить открытый ключ VAPID.
  3. Создайте http-маршрут, по которому клиенты могут отправлять информацию о своей подписке.
  4. Создайте http-маршрут, по которому клиенты могут запросить удаление информации о своей подписке.
  5. Когда захотите, используйте информацию о подписке для отправки подписчикам push-уведомлений.

Вот пример кода на стороне сервера:

Выполнено!

Итак, есть краткое изложение веб-технологий, позволяющих осуществлять обмен данными между сервером и клиентом. Если у вас нет очень специфического варианта использования, обычно лучше использовать веб-сокеты поверх событий на стороне сервера или Push API.