Как делать пуш-уведомления в мобильном приложении и зачем

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Всем привет, меня зовут Павел Тополь, я тимлид команды веб-разработки. Уже больше двух лет работаю над сайтом поиска работы Work.ua. В двух словах о проекте: это highload на PHP, кроме сайта, мы развиваем мобильное приложение для поиска работы. Думаю, это все, что нужно знать для понимания данной статьи. А в ней я хочу рассказать историю того, как мы делали у себя пуши.

Путь к пуш-уведомлениям

Зачем нам пуши и почему именно сейчас

Еще до того, как наше приложение попало в сторы, мы точно знали, что нам будут нужны пуши. Ведь какое современное приложение обходится без них? Оно и понятно, пуши — это весьма эффективный способ доставки информации пользователю, который еще и помогает вернуть его в приложение. Чего нельзя сказать о почте.

Почта — это больше про отложенное общение. Если вы пришлете пользователю письмо, маловероятно, что он тут же на него отреагирует. А если и отреагирует, то для этого ему нужно будет:

  1. Уйти из вашего приложения.
  2. Прочитать (в лучшем случае по диагонали) ваше письмо.
  3. Найти в нем ссылку.
  4. Перейти по ней.

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

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

Выбор сервиса отправки

Мобильное приложение Work.ua присутствует сразу на двух платформах — Android и iOS, и это сыграло свою роль при выборе сервиса для отправки пуш-уведомлений.

Изначально мы рассматривали вариант нативной отправки. Мы посмотрели на APNs, на web-пуши и, когда дело дошло до Android, обнаружили, что Firebase, по сути, и является той самой нативной платформой для отправки пушей для него. К тому же различные библиотеки пакета Firebase уже использовались в нашем мобильном приложении. Оказалось, что Firebase поддерживает мультиплатформенную отправку пушей. С одной стороны, это замечательно: отправляешь запрос в Firebase, даешь ему токен устройства, на которое нужно доставить пуш, и все. Дальше Firebase все сделает сам. Но поначалу нам показалось, что все слишком уж хорошо. Нас пугало то, что все это бесплатно.

Так как мы планировали отправлять много пушей (среднее значение сейчас — это приблизительно двести тысяч пушей в день), то если Firebase вдруг решит брать деньги за отправку уведомлений на сторонние платформы, это может обойтись нам в круглую сумму.

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

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

Наш первый пуш

Выбор тематики уведомления

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

  1. Массовость — нам нужно было сразу увидеть, какую пропускную способность мы можем обеспечить. Не хотелось бы попасть в ситуацию, где при отправке одного пуша все шло нормально, а при массовых рассылках мы просто положили серверы из-за нагрузки.
  2. Наличие посадочной страницы. Не все наши уведомления имели экраны, которые можно было бы показать пользователю при переходе из пуша.
  3. Полезность — мы подумали, что хоть уведомление об архивации резюме может быть полезно некоторым пользователям, большинство его не оценит. Пуш не должен был разочаровать пользователей, не должно было возникнуть желания сразу отписаться от пуш-уведомлений.

Таким образом нам удалось выделить три подходящих кандидата. И победителем из этой тройки вышел пуш «Новые рекомендуемые вакансии». Он был достаточно массовым, нам было куда вести пользователя при тапе на уведомление, ну и, конечно же, на наш взгляд, это уведомление было весьма полезным.

Проблемы внешних зависимостей

Для того чтобы не перенагружать и без того нагруженные серверы в дневное время, у нас принято запускать массовые рассылки ночью или рано утром, когда серверы еще не под сильной нагрузкой. Но нам бы не хотелось будить пользователей своими уведомлениями. Поэтому нам стоило придумать, как сделать рассылку днем и при этом не «положить» серверы.

Основная нагрузка у нас приходилась на серверы баз данных. Мы используем БД-кластер, состоящий из двух серверов. Один сервер — основной, второй — резервный, реплицирующийся с помощью drbd. И поскольку 99,9 процента времени резервный сервер простаивает, мы решили задействовать его в рассылке нашего пуша.

Первым делом мы запустили на нем sphinx и расчет дельта-индексов. Выделили для него IP-адрес, который всегда указывает на slave-сервер БД. Это нужно для того, чтобы мы могли спокойно поменять ротацию серверов, slave сделать мастером, а мастер — слейвом, и все продолжило бы работать. В случае если сервер недоступен, мы просто прерываем рассылку.

Архитектурные решения и итеративный подход

Любые HTTP-соединения к сторонним сервисам лучше всего делать асинхронно, иначе время выполнения вашего кода будет напрямую зависеть от времени ответа сервиса. В нашем случае для асинхронности мы использовали наш сервер очередей. Мы добавили воркер, задача которого — отправлять пуш-уведомления. И хотя Firebase API дает возможность отправлять пуш-уведомления не по одному за раз, а целыми «пачками» по 500 штук, в первой версии мы этого делать не стали.

Мы рассматривали пуш-уведомления как новый канал связи с пользователями. Было понятно, что через время пушей станет в разы больше, и просто собирать их в «пачки» в скриптах рассылки — это не лучший вариант. Как только появятся пуши по событию, скорость их рассылки будет неуклонно падать, потому что очередь может забиваться отправками по одному пушу. Единственный выход из этой ситуации — постоянно увеличивать количество воркеров, но в нашем случае это не вариант — сервера ведь не резиновые.

Все написанное выше продолжало оставаться для нас теорией, и хотелось проверить на практике, с какой скоростью мы сможем отправлять пуши в самом простом варианте: одна задача воркера — один пуш с отдельным подключением к Firebase. Мы сделали MVP — кроновый скрипт, который выбирал пользователей, подходящих по условиям для рассылки, и воркер, который отправлял пуш. И приступили к тестированию.

Первая рассылка

Наша первая рассылка выглядела следующим образом:

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

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

Шаг 3. Воркер, десериализующий объект пуша, трансформирующий его в необходимую для Firebase JSON-структуру и отправляющий пуш-уведомление в Firebase. Если Firebase нам отвечает, что токен устройства невалиден, этот воркер создает задачу на удаление невалидного токена из БД.

Шаг 4. Воркер, удаляющий токен из БД.

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

Первое, что мы заметили в логах, — иногда Firebase возвращал 5XX код ответа.

В документации в этом случае рекомендуется повторить запрос спустя какое-то время. Изначально мы не предусмотрели этот случай, поэтому пуши, на которые мы получали такой ответ, мы попросту не доставляли пользователю. Но после добавления ретраев, мы с этой проблемой не сталкивались.

Показатели производительности

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

При этом пропускная способность этого решения составила приблизительно 40 пушей в секунду. Может показаться, что это весьма неплохой результат, но на практике задержка между подготовкой данных и отправкой пуша могла достигать 15 минут, что для нас было неприемлемо. Это означало, что, когда пуш был фактически отправлен из очереди, данные, которые мы в нем отправляли, скорее всего, уже успели стать неактуальными. Нам нужно было либо замедлять этап подготовки данных, чего мы делать не хотели, потому что это растянуло бы рассылку, а нагрузка на сервер и так была небольшой, либо ускорять отправку, но даже максимальное количество воркеров не позволило бы нам сделать это так, чтобы пуши рассылались сразу после генерации данных. Поэтому нам нужно было придумать другой способ.

Ускорение отправки пушей

Трудности с legacy

Для того чтобы менеджить все воркеры, мы используем утилиту под названием GearmanManager. Утилита неплохая, со своей работой справлялась. Но для реализации нашей идеи ее возможностей не хватало. Большим минусом для нас стала негибкая реализация. Воркер — это либо колбек, либо класс с определенным именем и структурой (подробней об этом можно почитать в описании утилиты). Сам цикл обработки зашит в библиотеку, и без ее изменения нет возможности на него повлиять. А наша идея как раз заключалась в том, чтобы вмешаться в этот цикл.

Поиск и выбор решения

Вариантов было несколько. Сделать какой-то обходной путь для того, чтобы в файлах воркеров можно было как-то влезть в такой нужный нам цикл и создать на это PR. Но судя по активности, библиотека уже умерла. Можно было, конечно, пропатчить все это у себя локально, но мы решили, что это путь в никуда. Выбрали, на наш взгляд, самый правильный, но не самый простой вариант. Мы решили полностью отказаться от GearmanManager и заменить его на что-то более универсальное и актуальное. Наш взгляд пал на Supervisor.

Сложность варианта заключалась в том, что в перспективе мы хотели полностью отказаться от GearmanManager в пользу Supervisor. А это означало, что нам нужно было сразу продумать все абстракции: для того, чтобы в будущем с минимальными затратами перевести все существующие воркеры на использование Supervisor в качестве менеджера процессов. В итоге мы декомпозировали работу GearmanManager. Ту часть, которая отвечала за мониторинг процессов, мы отдали Supervisor. Нам осталось реализовать работу с Gearman-сервером и конфигурирование количества запускаемых воркеров для каждого из серверов.

Обновленная отправка

Проанализировав результаты рассылок, мы поняли, что большая часть времени при отправке пуша тратится на издержки при HTTP-соединении. Нам нужно было как-то их уменьшить, и это можно было сделать. Напомню, Firebase API позволяет передавать на отправку не по одному пушу, а «пачками» до 500 штук. Не нужно быть математиком, чтобы понять, что даже если сама задержка на ответ от Firebase будет немного больше, чем при отправке одного пуша, то мы все равно получим колоссальный прирост в скорости рассылки.

Идея заключалась в том, чтобы по-прежнему добавлять по одному сообщению в очередь, а воркеры по необходимости собирали бы их в «пачки» и отправляли на серверы Firebase. Таким образом мы получаем механизм, который в пиковые моменты собирает пачки по 500 пуш-уведомлений, а в обычное время может отправлять и по одному пушу.

Как оказалось, Gearman из коробки позволяет это сделать. Вся сила заключается в двух методах: setTimeout и wait. Мы определяем какое-то время, приемлемое для того, чтобы воркер придержал у себя уже готовый к отправке пуш. Для нас это было ≈25 секунд. Чтобы достичь этого времени, нам нужно было установить таймаут в 50 миллисекунд (25 / 500 * 1000). Таким образом, максимальная разница между получением задачи на отправку первого пуша и пятисотого будет ≤25 секунд.

В итоге у нас механизм, который получает задачу на отправку пуша, складывает пуш в «пачку», ожидает до 50 миллисекунд задачу от сервера. Если задача не появилось, срабатывает таймаут и мы отправляем все, что успели сложить в «пачку». Если же задача появилась, мы кладем в «пачку» и этот пуш и опять начинаем ждать. И так до тех пор, пока в «пачке» не оказывается 500 пушей.

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

Показатели производительности

Сказать что стало лучше — это ничего не сказать. Первая же рассылка показала колоссальный прирост в производительности. Пропускная способность нового подхода оказалась приблизительно на 800% выше. Разрыв между подготовкой данных для пуша и его отправкой сократился практически до 0. Теперь рассылка упиралась только во время, затраченное на подготовку данных для пуша. И такие показатели держатся до сих пор. Вот как рассылка выглядит на свежих графиках:

Выводы

Исследование рынка помогло нам понять, какие инструменты мы хотим использовать в работе. А изучение потребностей наших пользователей — определиться с тематикой первого пуш-уведомления. Мы поняли, что для нас в приоритете сделать MVP, а не потратить время на разработку идеального продукта.

В ходе работы мы также оценили промежуточные результаты и определились с метриками, за которыми наблюдали. Это помогло нам понять, где было «узкое горлышко», и устранить его. Финальное решение отправлять пуши «пачками», дало значительный прирост в скорости отправки. Надеюсь кейс, рассмотренный в данной статье, будет вам полезен.

👍НравитсяПонравилось8
В избранноеВ избранном5
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Почитав статью у меня сложилось впечатление что вы смешиваете event-based пуши с массовыми рассылками. Тут явное логическое разделение. event-based должны иметь больший приоритет и обрабатываться отдельно, т.к. предоставляют пользователю самую релевантную информацию. По хорошему они должны отправляться по одной с минимальной задержкой. Для массовых отправок задержки не так важны и их можно группировать.

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

Алексей, сейчас у нас максимально возможная задержка отправки уведомления 25 секунд. Мы считаем это приемлемым для текущих уведомлений.

А коли ви почнете видаляти з сайту фальшиві компанії згідно ваших умов користування:

1.3. Не розміщувати свідомо неякісну або фальшиву інформацію.

Раніше писав у підтримку, але фальшиву компанію залишили.

Оце вже цікавенько. А ну, пиши про них на DOU, як юзер кейз — як саме робити не треба, і як «дрібничка» у вигляді затикання каналів зворотного зв′язку «щоб не турбували» призводить до захвату маркетплейсу шахраями та перетворення на «ринок лимонів».

Це цілком айтішна стаття, але «верхнього рівня» ієрархії. Тобто, про побудову продуктових алгоритмів, а не про банальне галерне формошльопство.

І будь ласка, зацитуй там повністю свій лист, з адресою отримувача (якщо вона публічна або очевидна), та датою. Заодно подивися, як працює останній бастіон зворотного зв′язку в стагнуючих компаніях та організаціях. І не дивуйся: першою їх реакцією буде отписка та намагання сховати голову в пісок. Питання лише в тому, якою буде наступна, коли перша не спрацює — чи жевріє ще механізм підприємництва, чи вже мертвий.

Знайшли де сховати. Стрічку дуже мало хто читає, бо її засрали корпоративним булшитом.
Єдина неправда в статті — це те, що сервіси видаляють цей контент. Та вони на нього болт забили, там більше 90% цього лайна.

бо її засрали корпоративним булшитом

Також це бачу /lenta/interviews/creative-campus-softserve/

Ярославе, ми кожен день блокуємо десятки фальшивих компаній.

Щодо цієї компанії. Після вашого листа ми ще раз перевірили компанію, запросили в неї необхідні для нас дані. Порушень правил сайту ми не знайшли. Авжеж, це не означає, що роботодавець не обманює, але з досвіду можемо сказати, що на недобросовісну компанію одразу приходить відносна велика кількість обґрунтованих скарг. А за рік роботи цієї компанії з нами ваша скарга на цього роботодавця — єдина.
Якщо в вас з’явилося більше доказів, будь ласка, надішліть їх нам на support@work.ua, раптом ми досі помиляємося.

Щодо цієї компанії. Після вашого листа ми ще раз перевірили компанію, запросили в неї необхідні для нас дані. Порушень правил сайту ми не знайшли.
1.3. Не розміщувати свідомо неякісну або фальшиву інформацію.

Компанія публікується під вигаданим ім’ям!
Компанія на вашому сайті має значок «Перевірено» який означає що Дійсність компанії підтверджена:

Компанія надала адміністрації Work.ua свій код державної реєстрації в Україні.

Якщо ж компанія справжня то дайте посилання на її публічну інформацію, посилання на opendatabot.ua або youcontrol.com.ua буде достатньо!

Згідно закону України Про доступ до публічної інформації ви можете опублікувати посилання на ЄДР або номер цієї компанії в ЄДР!

Без згоди роботодавця ми не можемо надавати будь-яку додаткову інформацію. Краще за все звернутися до компанії та в неї запитати необхідну інформацію, можливо, вам її нададуть.

Без згоди роботодавця ми не можемо надавати будь-яку додаткову інформацію. Краще за все звернутися до компанії та в неї запитати необхідну інформацію, можливо, вам її нададуть.

Дмитро Слободян (керівник служби підтримки), ось це дійсно новина!

То ви відмовляєтесь надавати публічну інформацію про компанію?

Идиотский вопрос: что же вы спамите в таких-то количествах? Сказать что это много — не сказать ничего. Зная кто вы и что у вас за контент, рискну предположить что от ваших «услуг» откажутся 1 раз и навсегда, и только небольшой процент будет возвращаться спустя несколько лет.

Достать пользователя на самом деле сложно. Но если уж сумеете — считайте что вы в конечном пункте эротического путешествия. Особенно для тех, кто не знает, как это всё отключать.

Ну и совсем уж мелочи:
А что мешало запараллелить процесс?
А там точно надо было поднимать http1 соединение каждый раз, по сокету оно не пашет? Кроме http никаких api нет?

Алексей, аудитория действительно большая, поэтому и отправок много. Мы следим за тем, чтобы не отправлять пуши слишком часто и следим за динамикой отписок, когда увеличиваем число отправок. Вы можете почитать отзывы о приложении, и там будет сложно найти отзывы о назойливости: play.google.com/...​lient&showAllReviews=true.

Каким образом следите за динамикой отписок?

Алексей, запросом, который каждый день показывает количество новых отписок за вчера.

т.е. стата не на уровне пуша а общая за день?

На уровне пуша за день.

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

Есть то, чего вы отследить НЕ можете: неприятное впечатление, которое стимулирует пользователя больше к вам не входить. С какого-то момента ваш спам перестанут читать, даже важные сообщения. Ваш сайт будут игнорировать, как атеисты игнорируют призывы сектантов. И вы ничего не сможете с этим сделать — если не знаете как. А это «как» — на порядок дороже, чем просто не допускать такой ситуации массово. Иначе говоря, вы — НЕ знаете. И уж точно не я вам буду рассказывать о технологиях — которые тоже могут перестать работать из-за злоупотребления.

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

Разумеется, вы можете сыграть «на грани» и всё же привлечь внимание. Но вы же снова повторите предыдущие ошибки, и на этот раз блокировка умножится на фактор упрощения шаблона. Такой блок уже будет резким удешевлением бренда в глазах клиента. Даже ребрендинг не особо поможет.

Другими словами, формула AIDA работает как на развитие лояльности, так и на развитие отвращения. И крайне мало клиентов смогут даже озвучить, почему они не хотят. Не хотят и всё. Как вы не хотите есть землю — вам не нужно для этого причин, это просто не едят. Хотя малыши землю есть пробуют, это факт.

Шанс отследить реальное влияние — только прямым бета-тестированием, на реальных людях. Разговаривая о том, что и как происходит на самом деле. Да, это дорого. Но ничего другого у вас вообще нет. Однако, если у вас нет системы обратной связи, полностью ограждённой от прямого влияния руководства (а у вас нет, я проверял) — то и с реальными людьми ни одно звено вашей иерархии не может контачить, не нарушив принципы системы. А даже если сделает это по чисто человеческим соображением — попытка донести добытую информацию вызовет отторжение этого «глупого» кадра, посмевшего поставить под сомнение совершенство такого серьёзного предприятия своим ничтожным личным мнением.

Если кратко: слишком дешёвый механизм доступа к восприятию имеет побочное действие именно из-за своей дешевизны. Не имея высокоуровневой защиты от влияния, механизм восприятия аппелирует к глубинным механизмам страха и отвращения. Сломать которые уже невозможно, их эффект длительный, часто пожизненный.
Но вы даже не догадываетесь, что есть точно такие же положительные механизмы лояльности, которые тоже работают очень долгосрочно, и главное, бесплатно. Именно их вы навсегда закрываете, задействуя глупый дешёвый спам. И первый же конкурент, который не совершит этой ошибки — вышвырнет вас с рынка как охранник проигравшегося до нитки (уже) нищеброда из казино.

PS. 100 000, говорите? Давайте я вам скажу, кто они. Те, кто ищет любую работу (умея мало и работая плохо); мошенники (которые ищут, кому втереться в доверие); студенты, которые ищут первую работу. Грубо говоря, постоянных клиентов вы отшиваете, вы просто работаете на молодняк. И неизменно их теряете. Вы просто ждёте, когда вас вышвырнут с рыночной ниши. А это стоит в Украине очень недорого. Особенно, зная модели связей населения.

PPS. Фальшивые отзывы на Гугле — ай, молодцы. Нашли чем похвастаться.

Алексей, по теме отзывов — я имею ввиду негативные, и тут нам есть с чем и с кем сравнивать. И это сравнение не единственное, на что мы смотрим.

А что мешало запараллелить процесс?

Все и так работает параллельно. Для первого варианта у нас было пятнадцать воркеров, на разных серверах, который занимались отправкой пушей в Firebase. После внедрения подхода по сбору пушей в пачки, нам стало достаточно трех воркеров.

А там точно надо было поднимать http1 соединение каждый раз, по сокету оно не пашет? Кроме http никаких api нет?

Из-за того что мы делаем отправку пуша в воркере, соединение с Firebase открывается при первой отправке пуша и не закрывается все время жизни воркера, которое регулируется 2 парраметрами. временем и количеством отправок.

А можно поныть не про техническую часть? Когда я работал на крупных отечественных e-commerce проектах с айдиторией в 100-400к DAU (только про iOS могу сказать). Конверсия 1 пуша колебалась в пределах 0.3 — 1%. Отсюда вопрос о ценности пушей как таковых.

Эмметт, для нас ценность получается достаточно высокой, потому что приложение Work.ua представлено и для iOS и для Android.
На iOS у нас действительно конверсия ниже — средняя по всем пушам порядка 3%, а на Android значительно выше — в разные дни 8-10%. Но у отдельных типов уведомлений может достигать и 20-30%.

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

Щось ви навелосипедили, є ж уже готові опенсорсні рішення такі як github.com/appleboy/gorush

і відправляти можна не 500, а 1000

The value should be an array of registration tokens to which to send the multicast message. The array must contain at least 1 and at most 1000 registration tokens. To send a message to a single device, use the to parameter.

Я просмотрел предложенную вами библиотеку по диагонали и не понял как именно она должна была нам помочь?
Основная мысль — это то что мы кладем по одному пушу в очередь, а дальше выбираем из нее данные, собираем в пачки и отправляем в сторонний сервис(в нашем случае Firebase), который уже отправляет пуши на устройства.
Как я вижу, вы предложили альтернативу Firebase, но не способ как можно собирать пуши в пачки перед отправкой.
В двух словах о проблеме которую мы решали: мы так быстро просчитывали данные для пушей и так медленно их отправляли(потому что слали по одному), что задержка между просчетом данных и фактической отправкой пуше с этими данными могла достигать 10 минут, что в нашем случае неприемлемо.

Бібіотека вирішує проблему саме відправки пушів, всередині є вирішення проблем з чергами на відправку, обробку помилок / retry, підтримка Firebase + APN. А от сама підготовка даних, звичайно на вашій стороні. Просто стаття у вас про проблему відправки пушів, але в реальності основна проблема була не у відправці, а у підготовці данних.

Все еще не понимаю, чем именно помог бы этот сервис?

вирішення проблем з чергами на відправку

Да вроде не решает. Нам все так же нужно собирать пачки, перед отправкой данных в этот сервис. А поэтому нам все равно пришлось бы переходить на supervisord

обробку помилок

Мы хотим сами обрабатывать ошибки, для того чтобы иметь возможность удаля невалидные токены из хранилища

підтримка Firebase + APN

Сам Firebase с этим вроде как справляется

Остаются только ретраи. Но ставить и поддерживать для этого отдельный сервис нецелесообразно.

Да вроде не решает. Нам все так же нужно собирать пачки, перед отправкой данных в этот сервис. А поэтому нам все равно пришлось бы переходить на supervisord

вирішує, саму відправка менеджиться всередині сервісу, подивіться код) Проблема підготовки даних то вже інше питання

Мы хотим сами обрабатывать ошибки, для того чтобы иметь возможность удаля невалидные токены из хранилища

там є така можливість, він вертає масив токенів на які пуш не відправився

Сам Firebase с этим вроде как справляется

Суть подібних проектів у тому щоб використовувати нативні методи, тобто на андроід слати через firebase на іос через APN

Остаются только ретраи. Но ставить и поддерживать для этого отдельный сервис нецелесообразно.

Вам вирішувати.

Мій пойнт у тому що треба розмежовувати задачу підготовки та відправки даних, для відправки є повно готових рішень які вже все давно реалізували у себе. А от сама підготовка даних то уже задача під конкретний проект яку треба вирішувати самому

Как в PWA пуши делать на IOS ?

На stackoverflow довольно развернутый ответ на ваш вопрос, у вас не много опций.
stackoverflow.com/...​fications-to-ios-from-pwa

Это одна из причин, по которой для приложения work.ua мы откинули web-based solutions, и выбирали между нативной реализацией и Flutter, который компилируется в нативный код и имеет доступ ко всем платформенным API.

Да, тему изучал тоже. Варианты с хаком apple wallet фигня. Самый прикольный вариант это установка дополнительного приложения для пушей и общения с поддержкой, например для IOS. Остальное все сделать в PWA можно.

Подписаться на комментарии