Web-push: классика vs. альтернативы

Пытаемся прикрутить web-push уведомления к платформе.

Основные требования: безопасность, должны работать в фоне и на мобильных устройствах.

Классический способ

Использовать web-push API браузера, service worker и backend, который отправляет оповещения через push-сервис.

классическая реализация 👈

Из недостатков

Прослойка в виде push-сервиса принадлежит браузеру.

Её можно заменить на свой push сервис, но это сложно и дорого в реализации. Остается текущая прослойка и её нужно сделать безопасной.

Например, в Chrome — это FCM (Firebase Cloud Messaging).

Да, там есть шифрование и всё стандартизировано, но отсутствие возможности залезть в код и посмотреть, как работает — вызывает вопросы.

Способ через SSE

Классная штука, работает через HTTP.

Есть механизм ретраев, как сокеты держит соединение, но работает однонаправленно — от сервера к клиенту.

что такое SSE и как работает 👈

Нет прослойки в виде push-сервиса, подписываемся на событие EventSource, шлём пуши сервером, принимаем на клиенте.

Профит!

Но есть одно но

Способ не работает в фоне, а для PWA такое решение критично.

Service worker (SW) в фоне находится в режиме ожидания и реагирует только на свои события.

На другие события реагировать не умеет. Так реализовано для того, чтобы не сажать батарею в ноль.

Чтобы вывести SW из спячки, нужно, чтобы отработало событие, самого SW.

Итог

Получается, остаётся единственный рабочий вариант — использовать классический способ через push-сервис.

Сильно душно? 🙂

repost

284

input message

напишите коммент

еще контент в этом сообществе

еще контент в этом соообществе

войдите, чтобы увидеть

и подписаться на интересных профи

в приложении больше возможностей

пока в веб-версии есть не всё — мы вовсю работаем над ней

сетка — cоциальная сеть для нетворкинга от hh.ru

пересекайтесь с теми, кто повлияет на ваш профессиональный путь