Читать книгу Подталкивающие Web Push уведомления - Маргарита Акулич - Страница 5

Сервис-воркеры и Web Push сообщения с позиции технологии

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

Мы рассуждаем о Web Push сообщениях, а они в реале представлены технологиями – Push API и Notifications AP. Использование Push API происходит при передаче сообщения сервера сервис-воркеру. Использование же Notifications API имеет место при намерении показа пользователю сообщения сервис-воркера либо скрипта в самом Web-приложении.

В целях реализация механизма Web Push уведомлений прибегают к выполнению трех охарактеризованных ниже шагов:

1. Шаг, подразумевающий подготовку пользовательского интерфейса. Данным шагом предусматривается подготовка механизмов, благодаря которым пользователь сможет подписаться на сообщения.

2. Шаг, предполагающий отправку Web Push сообщения. Здесь осуществляется обращение к соответствующему API на сервере разработчика (Web-приложения), что обеспечивает реализацию процесса отправки сообщения на пользовательское устройство.

3. Шаг, предусматривающий прием Web Push сообщения. Это шаг обработки сообщения после его доставки в браузер.

О Push-сервисе

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

Push-сервисы не находятся под контролем разработчика веб-приложения, они являются по отношению к разработчику сторонними службами. Серверы разработчика обеспечивают взаимодействие с push-сервисами с помощью API. Примером push-сервиса является Google FСM.

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

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

API push-сервисов предоставляются инструменты, необходимые, чтобы уведомления отправлялись пользователям. Его представление обеспечено протоколом Web Push Protocol, являющимся стандартом IETF, дающим определение порядка работы с push-сервисами.

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

Для каждого из push-сообщений задаются свойства:

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

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

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