Руководства

Как добавить уведомления в приложение: внутри приложения, email и push

Чтобы добавить уведомления в веб-приложение, начните с уведомлений внутри приложения: таблицы уведомлений в базе данных и значка колокольчика, который показывает непрочитанные. Добавьте email для того, о чём людям нужно знать, когда их нет в приложении, с помощью почтового провайдера, а web push подключайте только тогда, когда своевременные оповещения действительно важны: он требует service worker, разрешения пользователя и, на iPhone, сохранения приложения на экран «Домой». Какие бы каналы вы ни выбрали, создавайте все уведомления в одном месте на сервере и позвольте пользователям выбирать, что они получают.

Этот гайд сравнивает каналы, показывает простую архитектуру и даёт промпты, которые можно использовать с ИИ-конструктором приложений.

Основные каналы в сравнении

КаналКогда доходит до пользователяУсилия на настройкуСтоимость в работеПодходит для
Внутри приложения (колокольчик, всплывающие подсказки)Когда пользователь в приложенииНизкиеТолько база данныхАктивность, упоминания, изменения статуса
EmailКогда пользователь проверяет почтуСредние: провайдер, настройка доменаОплата за письма по тарифу провайдераЧеки, дайджесты, всё важное
Web pushБраузер или установленное веб-приложение, даже когда сайт закрытСредние и вышеОбычно отправка бесплатнаСрочные оповещения
SMSПочти всегдаСредние; действуют правила о согласииОплата за сообщениеНапоминания о записи, срочные оповещения
Чат-инструменты (Slack, Teams)Когда пользователь на работеНизкие и средниеОбычно бесплатноВнутренние инструменты и командные оповещения

Большинству приложений нужны уведомления внутри приложения плюс email. Push и SMS стоит добавлять, когда время действительно важно, например при напоминании о записи или когда заказ готов.

Как устроена система уведомлений

Делайте её простой и централизованной:

  1. Что-то происходит. Оставлен комментарий, платёж не прошёл, запись назначена на завтра.
  2. Ваш сервер вызывает одну функцию, например notify(user, type, data).
  3. Эта функция проверяет настройки пользователя и записывает строку в таблицу notifications (для колокольчика).
  4. Затем она отправляет уведомление в другие каналы, которые пользователь включил для этого типа: email через вашего провайдера, push через Push API.
  5. Фронтенд показывает непрочитанные уведомления и отмечает их прочитанными, когда их открывают.

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

Что хранить

Таблица уведомлений обычно содержит: ID пользователя, тип (например, comment_reply), короткий заголовок и текст, ссылку на нужную страницу, время создания и время прочтения. Отдельная таблица настроек хранит, какие каналы пользователь хочет для каждого типа.

Показ новых уведомлений

  • Загружайте при открытии страницы и опрашивайте сервер каждые 30–60 секунд. Просто и надёжно.
  • Обновления в реальном времени через WebSockets или server-sent events работают мгновенно, но добавляют движущихся частей. Начните с опроса, если мгновенность не критична.

Email-уведомления

Для email нужен провайдер отправки и подтверждённый домен; подробности — в гайде как отправлять письма из приложения. Для уведомлений в частности:

  • Отправляйте с сервера, никогда не храните ключ провайдера в браузере.
  • Объединяйте частые события. «3 новых комментария» в одном письме лучше трёх писем.
  • Предложите ежедневный или еженедельный дайджест для событий с низким приоритетом.
  • Добавляйте ссылку на отписку или настройки в письмах, которые не являются обязательными. Правила для маркетинговых писем различаются по странам; проверьте, что применимо к вам.

Web push-уведомления

Web push позволяет сайту отправлять оповещения, которые выглядят как уведомления приложения. По документации MDN по Push API это работает так:

  1. Ваш сайт регистрирует service worker — скрипт, который браузер может выполнять в фоне.
  2. После согласия пользователя service worker подписывается через PushManager.subscribe(). Браузер возвращает подписку с endpoint и ключами шифрования.
  3. Ваш сервер сохраняет эту подписку и, когда что-то происходит, отправляет сообщение на endpoint, обычно подписанное ключами VAPID (парой ключей, которая идентифицирует ваш сервер).
  4. Браузер запускает ваш service worker, который показывает уведомление, даже если страница не открыта.

MDN также отмечает, что endpoint нужно держать в секрете: зная его, можно отправлять сообщения этому пользователю.

iPhone и iPad

WebKit добавил Web Push для веб-приложений в iOS и iPadOS 16.4 с двумя условиями из его объявления: сайт должен быть добавлен на экран «Домой», а разрешение нужно запрашивать в ответ на действие пользователя, например нажатие кнопки «Подписаться». Значит, на iPhone push доходит только до тех, кто установил ваше веб-приложение. Что значит установка веб-приложения, см. в гайде нативные приложения и progressive web apps.

Как правильно просить разрешение

Не запрашивайте разрешение при первом визите. Сначала объясните пользу («Получайте напоминание за час до занятия»), а системный запрос браузера показывайте, когда пользователь нажимает кнопку. Если человек откажет, браузер может не дать вам спросить снова, поэтому преждевременный запрос может потерять пользователя навсегда.

Запланированным уведомлениям нужен триггер

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

Промпты для ИИ-конструктора

Начните с уведомлений внутри приложения:

Добавь уведомления внутри приложения. Создай таблицу notifications (user, type, title, body, link, created_at, read_at). Добавь серверную функцию notify(userId, type, data), которую вызывает каждая функция. В шапке покажи значок колокольчика с количеством непрочитанных, выпадающий список последних 20 уведомлений и кнопку «Отметить все как прочитанные». Опрашивай сервер на новые каждые 60 секунд.

Затем настройки и email:

Добавь настройки уведомлений: для каждого типа (ответы на комментарии, упоминания, оплата) пользователь выбирает: внутри приложения, email, оба варианта или ничего. notify() должна учитывать эти настройки. Отправляй email через [ПРОВАЙДЕР], используя секрет [ИМЯ_ПЕРЕМЕННОЙ], только на сервере. Группируй письма о комментариях, чтобы один пользователь получал не больше одного письма за 15 минут.

Затем push, если он вам нужен:

Добавь необязательные web push-уведомления. Зарегистрируй service worker, сгенерируй VAPID-ключи и сохрани приватный ключ как секрет. Добавь в настройках кнопку «Включить уведомления», которая запрашивает разрешение только после нажатия. Сохраняй каждую подписку для пользователя и устройства, отправляй push из notify(), если пользователь включил его, и удаляй подписки, которые сервис push сообщает как истёкшие.

Частые ошибки

  • Уведомления разбросаны по коду. Каждая функция отправляет свои письма по-своему, и настройки игнорируются. Используйте одну функцию notify().
  • Запрос разрешения на push при загрузке страницы. Большинство откажется, и второго шанса может не быть.
  • Нет настроек. Пользователи, которые не могут отключить шумные оповещения, отключают все или уходят.
  • Отправка из браузера. Ключи email и push должны быть только на сервере.
  • Неочищенные мёртвые push-подписки. Истёкшие подписки копятся и тратят отправки впустую.
  • Чувствительные данные в тексте уведомления. Экран блокировки показывает его. «У вас новое сообщение» безопаснее самого сообщения.
  • Нет журнала отправленного. Когда пользователь пишет «я не получил письмо», логи с ID сообщений у провайдера помогут выяснить причину.

Чек-лист

  • Одна серверная функция notify(), которую используют везде
  • Таблица уведомлений с состоянием прочтения и колокольчик с количеством непрочитанных
  • Настройки каналов для каждого типа, которые учитывает notify()
  • Email отправляется с сервера с подтверждённым доменом; дайджест или группировка для частых событий
  • Разрешение на push запрашивается только после действия пользователя, с объяснением
  • Push проверен на компьютере и на iPhone с приложением на экране «Домой»
  • Истёкшие push-подписки удаляются
  • В тексте push и превью email нет чувствительных данных
  • У запланированных напоминаний есть надёжный триггер

Уведомления в Mythex

Mythex не включает встроенного сервиса email или push для созданных вами приложений, поэтому вы подключаете собственного почтового провайдера и генерируете свои push-ключи, которые хранятся как секреты проекта. Для части внутри приложения нужна только база данных проекта, которую Mythex добавляет по вашему запросу. Создавайте функции промптами, похожими на приведённые выше, проверяйте колокольчик и письма в Preview, а push — на опубликованном URL, потому что service worker и push работают только по реальному HTTPS-адресу. В документации есть рецепт отправка email из приложения со стартовым промптом. Mythex не документирует запланированные задачи, поэтому напоминания по времени планируйте с внешним триггером, как описано в как запускать фоновые задачи.

Вопросы

Какое уведомление проще всего добавить в веб-приложение?

Уведомления внутри приложения: таблица уведомлений в базе данных и значок колокольчика, который показывает непрочитанные. Им не нужен сторонний сервис. Следующий шаг — email, для него понадобится почтовый провайдер.

Может ли веб-приложение отправлять push-уведомления на iPhone?

Да, но с ограничениями. WebKit добавил Web Push для веб-приложений на экране «Домой» в iOS и iPadOS 16.4, поэтому пользователь сначала должен добавить ваше веб-приложение на экран «Домой», а разрешение нужно запрашивать после нажатия, например на кнопке «Подписаться».

Работают ли push-уведомления, когда сайт закрыт?

Да. Push API доставляет сообщения service worker вашего сайта, который браузер запускает при получении сообщения, поэтому страница не обязана быть открытой. Пользователь должен сначала дать разрешение.

Как не раздражать пользователей уведомлениями?

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

Mythex · Pricing · Создавайте что угодно с ИИ · Шаблоны сайтов и приложений · Сравнения Mythex · Глоссарий по созданию приложений с ИИ · Бесплатные инструменты для создания приложений с ИИ · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)