У вас есть существующее приложение или API, которое использует электронную почту/смс для уведомлений о конкретных событиях. Поскольку сервис-воркеры становятся стандартом в WebKit, мы все должны начать рассматривать возможность использования WebPush (наряду со всеми преимуществами кэширования).
Чтобы начать пользоваться преимуществами, нам нужно будет внести коррективы как на стороне клиента, так и на стороне сервера. У каждого из них есть свои роли, давайте рассмотрим их сейчас.
Сторона клиента
Клиентская сторона играет ценную роль в фактической установке сервис-воркера, жизненно важной части головоломки, когда речь идет о Web Push. Наряду с фактической обработкой Web Push при отправке запроса.
После первоначальной установки сервис-воркера ваш интерфейс должен позволять пользователю подписываться на push-уведомления. Это может быть обработано с помощью простой кнопки вместе с простой обработкой кликов Javascript.
Этот процесс дает уникальную конечную точку, ключ и секрет, которые потребуются нашему серверу для отправки push-уведомлений пользователю. Итак, на этом этапе мы должны отправить запрос на наш сервер, попросив его сохранить эти данные (если возможно, привязать их к пользователю) для будущего использования.
Сторона сервера
Серверная сторона играет столь же ценную роль, поскольку ей необходимо фактически хранить конечные точки push-уведомлений и иметь дело с фактической отправкой push-запросов через Интернет.
Чтобы настроить это, вам действительно нужен SSH-доступ к серверу, виртуальный хостинг просто не будет работать.
Также, скорее всего, будет SDK для выбранного вами языка. Здесь есть полезная коллекция: https://github.com/web-push-libs/web-push, каждая со своей инструкцией по установке.
В моем случае я предпочитаю использовать Laravel для сценариев на стороне сервера. Поэтому я использую библиотеку PHP Web Push, которую можно быстро установить через composer.
После установки вам нужно просто сохранить детали, переданные со стороны клиента, и настроить функции для фактической отправки уведомлений Web Push.
Схема потока данных
Прочитав вышеизложенное, вы можете подумать, что происходит много всего. Вы правы, но, на первый взгляд, не нужно много усилий, чтобы начать пожинать плоды Web Push. Позвольте мне описать стандартный поток, который должен быть одинаковым для большинства приложений.
- Пользователь загружает ваш сайт/веб-приложение
- Service Worker устанавливается с помощью тега скрипта, связанного с индексным файлом.
- Выполняется проверка, чтобы убедиться, что текущий клиент поддерживает Web Push (iOS… соберитесь!)
- Предполагая, что проверки проходят успешно, появляется кнопка для включения push-уведомлений.
- Нажатие кнопки запускает рабочий процесс push-подписки сервис-воркеров.
- Когда это удается, функция обратного вызова отправляет результаты на нашу серверную часть для хранения.
- Если пользователь аутентифицирован, мы также передаем это на сервер.
- Получив запрос от внешнего интерфейса, наша серверная сторона должна сохранить данные на постоянном носителе (таблице базы данных) вместе с привязкой этих данных к пользователю. Помните, что у пользователя может быть несколько регистраций web push (несколько устройств)
- Все соответствующие данные теперь сохранены, все, что осталось сделать, это вызвать нашу функцию Web Push, которая отправляет push-уведомление в нужную конечную точку.
- Затем клиентская сторона ловит это (используя сервис-воркер) и предоставляет пользователю push-уведомление.
Вывод
Ну, что же вы ждете? Web Push становится все более и более доступным, а с Server Side SDK барьер для входа становится все меньше и меньше. Пришло время всем нам начать пользоваться преимуществами, особенно в форме веб-приложений, которые полагаются на электронную почту для уведомлений за пределами самого приложения.
Если кто-то хочет увидеть несколько примеров кода или стандартное веб-приложение, я был бы рад выложить что-нибудь на Github. Просто дайте мне знать в комментариях.
Потрясающий! Вы дошли до конца. Хотите поболтать со мной? Напишите мне сообщение в Твиттере!
