Представим, что пользователь зарегистрировался в веб-приложении, оплатил подписку и запустил обработку документа с помощью AI-модели. Через несколько минут обработка завершилась, но пользователь уже закрыл страницу. Как сообщить ему, что результат готов?
Можно отправить email, показать уведомление при следующем входе или, если пользователь разрешил, доставить браузерное push-уведомление. Но если отправлять все три сообщения без каких-либо правил, человек быстро начнёт воспринимать их как спам.
Поэтому система уведомлений в веб-приложении — это не просто функция отправки сообщений. Это отдельный механизм, который связывает события продукта, предпочтения пользователя, способы доставки и историю взаимодействий.
Хорошо спроектированные уведомления помогают человеку завершать действия, возвращаться к важным результатам и вовремя узнавать о проблемах. Плохо спроектированные отвлекают, раздражают и создают ненужную нагрузку на инфраструктуру.
В этой статье разберём, как сделать уведомления на сайте, чем отличаются email, Web Push и внутренние сообщения, как реализовать основные компоненты на Python и FastAPI и какие ошибки стоит предусмотреть ещё до запуска продукта.
Зачем веб-приложению нужны уведомления
Уведомления решают несколько разных задач. Первая — подтверждение важных действий. Например, пользователь создал аккаунт, изменил пароль или успешно оплатил заказ. Вторая — информирование о завершении длительной операции. Это особенно актуально для приложений, которые генерируют изображения, обрабатывают видео или анализируют документы.
Третья — напоминания. Пользователь может получить сообщение о приближающемся сроке, незавершённой задаче или запланированном событии. Четвёртая — сообщения о взаимодействии с другими людьми. Например, новый комментарий, приглашение в проект или упоминание в обсуждении.
Уведомления для пользователей сайта должны быть связаны с реальной пользой. Если сообщение не помогает человеку принять решение или выполнить действие, стоит задуматься, действительно ли его нужно отправлять.
Какие бывают уведомления
В современных веб-приложениях используются разные каналы доставки. Виды уведомлений в веб-приложении различаются не только технической реализацией, но и ожиданиями пользователя. Например, сообщение о новом комментарии удобно показывать внутри приложения. Подтверждение изменения пароля логично отправить на email. А уведомление о готовности длительной AI-генерации может быть полезно через push, если пользователь дал разрешение.
Необязательно поддерживать все каналы с первого дня.
Чем уведомление отличается от события
Представим, что пользователь завершил оплату. Это событие продукта: payment.succeeded На его основании система может создать несколько действий: payment.succeeded ↓ Создать уведомление ↓ Отправить email ↓ Показать сообщение в кабинете Событие описывает то, что произошло. Уведомление — то, что необходимо сообщить человеку. Событийная архитектура уведомлений позволяет разделять бизнес-логику и доставку сообщений.
Например, модуль платежей не должен самостоятельно формировать HTML-письмо, обращаться к почтовому провайдеру и управлять push-подписками. Его задача — корректно зафиксировать успешную оплату.
Как выглядит архитектура сервиса уведомлений
Для небольшого Full Stack приложения достаточно нескольких логических компонентов. Backend ↓ Бизнес-событие ↓ Notification Service ↓ Проверка настроек пользователя ↓ Создание уведомления ↓ Очередь доставки ├── Email Worker ├── Push Worker └── In-app Storage Так выглядит архитектура сервиса уведомлений.
Необязательно выделять Notification Service в отдельный микросервис. На раннем этапе он может быть обычным модулем внутри Python Backend. Главное — отделить решение о том, кому и что сообщить, от конкретного способа доставки.
Какие уведомления отправлять обязательно
Не все сообщения имеют одинаковое значение. Например, подтверждение важной операции с аккаунтом отличается от предложения посмотреть новую статью. Условно можно выделить транзакционные, продуктовые и маркетинговые сообщения. Транзакционные уведомления сайта связаны с действиями пользователя или состоянием его аккаунта: подтверждением регистрации, восстановлением доступа, оплатой или изменением настроек безопасности.
Продуктовые уведомления помогают работать с сервисом: сообщают о готовом отчёте, комментарии или приглашении. Маркетинговые сообщения предназначены для продвижения и обычно требуют отдельного управления согласием и предпочтениями пользователя в соответствии с применимыми правилами. Эти категории полезно разделять с самого начала.
Почему нельзя отправлять все уведомления одинаково
Представим пользователя, который отключил рекламную рассылку. Это не обязательно означает, что он должен перестать получать сообщения о безопасности аккаунта или подтверждения оплаченных заказов. Поэтому настройки уведомлений пользователя должны учитывать категории сообщений и каналы доставки. Например: Безопасность аккаунта — email Оплата заказа — email Новые комментарии — in-app Завершение AI-задачи — push
Маркетинговые предложения — отключены Такая модель делает поведение продукта предсказуемым и помогает уважать выбор пользователя.
Как хранить уведомления в базе данных
Для внутренних уведомлений обычно нужна таблица, которая связывает сообщение с получателем. Пример структуры: CREATE TABLE notifications ( id BIGSERIAL PRIMARY KEY, user_id BIGINT NOT NULL, event_key VARCHAR(150), type VARCHAR(80) NOT NULL, title VARCHAR(200) NOT NULL, body TEXT NOT NULL, target_url TEXT, is_read BOOLEAN NOT NULL DEFAULT FALSE, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), read_at TIMESTAMPTZ );
Это упрощённая таблица уведомлений PostgreSQL. В реальном проекте user_id обычно связывается внешним ключом с таблицей пользователей, а для эффективного получения списка добавляется индекс по получателю и времени создания.
Поле event_key может использоваться для предотвращения повторного создания одного и того же уведомления. Для этого нужна соответствующая уникальная политика на уровне базы, а не только проверка в Python.
Почему нужно хранить историю уведомлений
Представим, что пользователь получил сообщение о завершении отчёта, но не открыл его сразу. Если уведомление существует только в памяти браузера, после перезагрузки страницы оно исчезнет. Хранение истории уведомлений позволяет показать сообщения при следующем входе. Пользователь может открыть центр уведомлений, посмотреть предыдущие события и перейти к связанным объектам.
Но хранить сообщения бесконечно необязательно. Для каждого типа данных полезно определить разумный срок хранения и правила удаления.
Как реализовать API уведомлений на FastAPI
Начнём с простого примера. Допустим, данные уже сохраняются в базе через отдельный repository. Тогда маршруты могут выглядеть так: from fastapi import FastAPI, Depends from pydantic import BaseModel app = FastAPI() class NotificationResponse(BaseModel): id: int title: str body: str is_read: bool @app.get( "/notifications", response_model=list[NotificationResponse] ) def get_notifications(
user=Depends(get_current_user) ): return notification_repository.list_for_user( user_id=user.id, limit=30 ) Здесь get_current_user и notification_repository — компоненты существующего приложения, которые необходимо реализовать отдельно. Важный момент: API уведомлений на FastAPI должно определять пользователя через проверенную авторизацию, а не доверять произвольному user_id из параметров запроса.
Иначе один пользователь сможет попытаться прочитать чужие уведомления.
Как отметить уведомление прочитанным
Обычно пользователь нажимает на сообщение, после чего оно становится прочитанным. Для этого можно создать endpoint: @app.patch("/notifications/{notification_id}/read") def mark_notification_read( notification_id: int, user=Depends(get_current_user) ): updated = notification_repository.mark_read( notification_id=notification_id, user_id=user.id ) if not updated: raise HTTPException( status_code=404,
detail="Notification not found" ) return {"status": "read"} При реализации нужно импортировать HTTPException из FastAPI. Отметка уведомления как прочитанного должна выполняться только для уведомления текущего пользователя. Самый надёжный вариант — включать проверку владельца непосредственно в запрос обновления: UPDATE notifications SET is_read = TRUE, read_at = COALESCE(read_at, NOW()) WHERE id = :notification_id
AND user_id = :user_id; Так можно избежать ситуации, когда проверка доступа и изменение данных выполняются несогласованно.
Как показывать непрочитанные уведомления
В интерфейсе часто используется значок колокольчика со счётчиком. Например: Уведомления (3) Для этого Backend может предоставлять отдельный endpoint: GET /notifications/unread-count Счётчик непрочитанных уведомлений удобнее рассчитывать по серверным данным, а не только по локальному состоянию браузера. Если пользователь прочитал сообщение на телефоне, состояние должно обновиться и на компьютере.
Для небольшого приложения обычного SQL-запроса достаточно. Кэширование стоит рассматривать только после появления реальной необходимости.
Как создать уведомление при событии
Представим, что AI-сервис завершил анализ документа. Worker сохраняет результат, после чего создаёт уведомление: def on_document_processed( user_id: int, document_id: int ): notification_service.create( user_id=user_id, type="document_ready", title="Документ обработан", body="Результат анализа готов.", target_url=f"/documents/{document_id}" ) Это пример создания уведомления из Backend-события.
Важное условие: уведомление должно создаваться после того, как результат действительно сохранён и доступен пользователю. Если сначала отправить сообщение, а затем операция сохранения завершится ошибкой, человек перейдёт по ссылке и не увидит результата.
Почему уведомления лучше отправлять через очередь
Отправка email или push обычно предполагает обращение к внешнему сервису. Если делать это прямо внутри основного HTTP-запроса, пользователь будет ждать ответа провайдера. Поэтому очередь отправки уведомлений помогает отделить основную бизнес-операцию от доставки. Например: Платёж подтверждён ↓ Заказ обновлён ↓ Создано событие уведомления ↓ Email Worker ↓ Почтовый провайдер
Для реализации можно использовать Celery, Redis и другие инструменты фоновой обработки. Однако очередь сама по себе не гарантирует, что письмо будет отправлено ровно один раз. Повторные попытки и сбои нужно учитывать отдельно.
Как отправить email на Python
Для отправки электронной почты существует несколько подходов. Можно использовать SMTP или API специализированного почтового провайдера. Для небольшого проекта SMTP бывает удобным стартовым вариантом. Пример:
import os
import smtplib
from email.message import EmailMessage def send_email(to_email: str, subject: str, body: str): message = EmailMessage() message["From"] = os.environ["SMTP_FROM"] message["To"] = to_email message["Subject"] = subject message.set_content(body) with smtplib.SMTP( os.environ["SMTP_HOST"], int(os.environ.get("SMTP_PORT", "587")), timeout=15 ) as smtp: smtp.starttls() smtp.login( os.environ["SMTP_USERNAME"],
os.environ["SMTP_PASSWORD"] ) smtp.send_message(message) Это базовая отправка email через Python SMTP. Для production необходимо дополнительно учитывать требования провайдера, обработку ошибок, TLS-конфигурацию, ограничения отправки и защиту учётных данных. SMTP-пароль нельзя хранить непосредственно в исходном коде.
SMTP или Email API
SMTP — стандартный протокол отправки электронной почты. Email API — интерфейс специализированного сервиса, который позволяет отправлять сообщения через HTTP-запросы. SMTP или Email API для сайта — выбор, зависящий от требований проекта. API-провайдеры нередко предоставляют удобные инструменты для шаблонов, статистики доставки, обработки отказов и управления отправителями.
SMTP может быть достаточным для небольших объёмов и простых сценариев. В обоих случаях нужно помнить: успешный ответ сервиса отправки не означает, что письмо гарантированно оказалось во входящих получателя.
Почему email может не дойти
Электронная почта — сложная система доставки. Письмо может быть принято сервером отправки, но затем отклонено, отложено или помещено в спам. Причины включают неправильную настройку домена, плохую репутацию отправителя, ошибки адреса и ограничения принимающего сервера. Поэтому доставляемость email-уведомлений зависит не только от Python-кода.
Для реального продукта важно правильно настроить домен отправителя и механизмы почтовой аутентификации, включая SPF, DKIM и DMARC. Также необходимо обрабатывать уведомления о недоставленных письмах, если провайдер предоставляет такую возможность.
Зачем нужны шаблоны email
Представим три типа сообщений:
- подтверждение регистрации;
- успешная оплата;
- готовность AI-отчёта.
Если HTML и текст каждого письма собирать непосредственно в обработчиках Backend, код быстро станет неудобным. Поэтому шаблоны email для веб-приложения лучше хранить отдельно от бизнес-логики. Например: templates/ ├── welcome.html ├── payment_success.html └── report_ready.html Шаблон получает необходимые переменные: имя пользователя, название продукта или ссылку на результат.
Важно корректно экранировать пользовательские данные, чтобы содержимое сообщения не превращалось в произвольный HTML.
Почему нужны текстовые версии писем
Не все почтовые клиенты одинаково отображают HTML. Поэтому полезно отправлять письмо в формате multipart/alternative, где присутствуют текстовая и HTML-версии. HTML и текстовые email-уведомления помогают сделать сообщения доступнее и совместимее с разными клиентами. Также не стоит размещать всю важную информацию только на изображении: некоторые почтовые приложения блокируют автоматическую загрузку картинок.
Как работают уведомления внутри приложения
In-app уведомления отображаются непосредственно в интерфейсе сайта. Обычно пользователь видит колокольчик, список событий и отметки о прочтении. Например: Уведомления ● Ваш отчёт готов ● Анна оставила комментарий ○ Подписка успешно продлена In-app уведомления на сайте удобны тем, что не требуют доступа к почтовому ящику или разрешения браузера на push.
Они хорошо подходят для событий, которые пользователь может просмотреть при следующем посещении продукта. Но если человек не открывает сайт, такое сообщение само по себе не привлечёт его внимание.
Как реализовать центр уведомлений
Frontend запрашивает последние сообщения через API и отображает их в выпадающем меню или на отдельной странице. Для больших списков нужна пагинация. Например: GET /notifications?limit=20&cursor=... Центр уведомлений в веб-приложении должен поддерживать понятные состояния: загрузка, отсутствие сообщений, ошибка получения данных и наличие непрочитанных уведомлений.
Не стоит автоматически удалять уведомление сразу после открытия меню. Пользователь мог увидеть список, но не прочитать каждое сообщение.
Как обновлять уведомления без перезагрузки страницы
Есть несколько вариантов. Самый простой — периодически запрашивать новые данные. Например, раз в 30–60 секунд, если такая частота подходит продукту. Другой способ — использовать WebSocket или Server-Sent Events. Обновление уведомлений в реальном времени полезно для чатов, совместной работы и других сценариев, где задержка доставки имеет значение. Для обычного личного кабинета polling часто оказывается достаточным.
Выбор зависит от частоты событий и требований к пользовательскому опыту.
Что такое WebSocket для уведомлений
WebSocket позволяет поддерживать двустороннее соединение между браузером и сервером. После установления соединения Backend может отправлять новые события без отдельного HTTP-запроса на каждое обновление. Например:
Frontend ← WebSocket → Backend
WebSocket уведомления в FastAPI могут быть полезны, если приложение должно оперативно показывать новые сообщения. Однако при нескольких Backend-инстансах потребуется продумать передачу событий между процессами и управление подключениями. WebSocket не заменяет постоянное хранение уведомлений. Если пользователь был offline, сообщение должно оставаться доступным после возвращения.
Что такое Server-Sent Events
Server-Sent Events, или SSE, — механизм, позволяющий серверу отправлять события браузеру через длительное HTTP-соединение. В отличие от WebSocket, SSE ориентирован прежде всего на одностороннюю передачу данных от сервера к клиенту. SSE для уведомлений сайта может быть удобным решением, если Frontend должен только получать обновления. Например, сервер сообщает, что AI-задача завершилась или появился новый комментарий.
При выборе SSE нужно учитывать особенности инфраструктуры, переподключения и авторизации.
Что такое Web Push
Web Push позволяет отправлять уведомления через браузерную инфраструктуру, в том числе когда страница сайта не открыта, если платформа и настройки пользователя поддерживают такой сценарий. Обычно используются Service Worker, Push API и Notifications API. Web Push уведомления для сайта отличаются от обычных сообщений внутри интерфейса.
Они требуют разрешения пользователя и зависят от поддержки браузера, операционной системы и настроек устройства. Поэтому Web Push нельзя считать гарантированным способом доставки каждого сообщения.
Как работает браузерная push-подписка
Упрощённая последовательность: Пользователь разрешает уведомления ↓ Браузер создаёт push-подписку ↓ Frontend передаёт подписку Backend ↓ Backend сохраняет данные подписки ↓ Push-сервис доставляет сообщение ↓ Service Worker показывает уведомление Так устроена подписка на push-уведомления в браузере. Важная деталь: разрешение браузера и регистрация push-подписки — связанные, но разные операции.
Также нужно учитывать, что пользователь может отозвать разрешение или удалить подписку.
Зачем нужен Service Worker
Service Worker — специальный браузерный механизм, который может обрабатывать определённые события независимо от обычного JavaScript-кода страницы. Для Web Push он принимает push-событие и может показать уведомление через Notifications API. Service Worker для push-уведомлений является важной частью браузерной реализации. Например, обработчик может выглядеть так: self.addEventListener("push", (event) => {
const data = event.data ? event.data.json() : {}; event.waitUntil( self.registration.showNotification( data.title || "Новое уведомление", { body: data.body || "", icon: "/icon.png" } ) ); }); Это упрощённый пример обработчика. В production необходимо дополнительно проверять структуру данных и безопасно обрабатывать переходы по ссылкам.
Как запросить разрешение на уведомления
Браузер не должен получать запрос разрешения неожиданно, сразу после открытия сайта. Лучше сначала объяснить пользователю, зачем нужны уведомления. Например, после запуска длительной обработки можно предложить включить сообщения о готовности результата. Запрос разрешения на push-уведомления должен быть связан с понятным пользовательским действием. Пример: async function enableNotifications() {
if (!("Notification" in window)) { return; } const permission = await Notification.requestPermission(); if (permission === "granted") { console.log("Notifications allowed"); } } Это только запрос разрешения. Для полноценной Web Push доставки дополнительно понадобятся Service Worker, Push API, серверная подписка и отправка через push-сервис.
Почему push-уведомления требуют HTTPS
Многие браузерные возможности, связанные с Service Worker и Push API, доступны только в безопасном контексте. Поэтому HTTPS для Web Push уведомлений является практическим требованием для production-сайта. При локальной разработке браузеры могут предоставлять исключения для localhost. Но в рабочем окружении необходимо использовать корректно настроенный HTTPS.
Что такое VAPID
VAPID — механизм идентификации сервера приложения при отправке Web Push. Для этого используются ключи, связанные с отправителем. VAPID ключи для Web Push применяются при создании и обслуживании push-подписок. Публичный ключ может использоваться на Frontend, а приватный должен храниться только на сервере.
Не следует путать VAPID с пользовательской авторизацией: наличие подписки не означает, что любой клиент может произвольно отправлять уведомления другим пользователям.
Как хранить push-подписки
Один пользователь может использовать несколько браузеров и устройств. Поэтому удобнее хранить push-подписки отдельно от основной таблицы пользователей. Например: push_subscriptions id user_id endpoint p256dh_key auth_key created_at last_used_at Хранение Web Push подписок позволяет отправлять сообщения на несколько устройств одного пользователя.
При этом данные подписки следует защищать, а недействительные подписки удалять или деактивировать после соответствующих ответов push-сервиса.
Почему нельзя гарантировать доставку push
Пользователь может отключить уведомления, удалить браузер, изменить устройство или находиться offline. Операционная система также может ограничивать показ сообщений. Поэтому надёжность доставки push-уведомлений не равна стопроцентной гарантии показа. Для важных событий полезно сохранять уведомление внутри приложения, даже если дополнительно отправляется push.
Тогда пользователь сможет увидеть сообщение при следующем входе.
Как не отправлять одинаковые сообщения несколько раз
Представим, что платёжный провайдер дважды прислал уведомление об успешной оплате. Если каждый Webhook напрямую запускает отправку письма, пользователь может получить два одинаковых сообщения. Поэтому защита от дублирования уведомлений должна быть предусмотрена на уровне бизнес-событий. Например, можно создать уникальный ключ: payment_success:order_125
Если уведомление с таким ключом уже создано, повторное событие не должно создавать новую запись. Но одной проверки if exists недостаточно при конкурентной обработке. Для надёжности нужен уникальный индекс или ограничение базы данных.
Почему доставка тоже может повторяться
Даже если уведомление создано один раз, worker может отправить его повторно после сбоя. Например, почтовый провайдер принял письмо, но worker завершился до сохранения результата. Система не знает, была ли доставка успешной, и повторяет задачу. Поэтому идемпотентность отправки уведомлений имеет ограничения, зависящие от внешнего канала.
Если провайдер поддерживает собственные ключи идемпотентности, их полезно использовать. В остальных случаях важно минимизировать вероятность дублей и учитывать неопределённые результаты доставки.
Как хранить статусы доставки
Внутреннее уведомление и попытка его доставки — разные сущности. Одно уведомление может отправляться через email и push. Поэтому полезно иметь отдельную таблицу: notification_deliveries id notification_id channel status attempt_count last_error created_at sent_at Статусы доставки уведомлений могут включать: pending sending sent failed
При этом sent обычно означает, что сообщение принято системой доставки, а не обязательно прочитано конечным пользователем. Для email некоторые провайдеры дополнительно сообщают о доставке, отказах и других событиях.
Как обрабатывать ошибки отправки
Представим, что почтовый провайдер временно недоступен. Worker может повторить попытку позже. Но если адрес пользователя недействителен, бесконечные повторения не помогут. Поэтому повторные попытки отправки уведомлений должны различать временные и постоянные ошибки. Для временных сбоев полезны ограниченное число retry и увеличивающиеся интервалы ожидания.
Для постоянных ошибок лучше сохранить причину и прекратить автоматические попытки.
Почему важны лимиты отправки
Представим сервис совместной работы, где один пользователь за минуту оставил 100 комментариев. Если каждый комментарий вызывает отдельный email, получатель получит 100 писем. Технически система может работать правильно, но пользовательский опыт будет плохим. Поэтому ограничение частоты уведомлений помогает предотвращать спам и избыточную нагрузку.
Можно использовать объединение событий, задержку отправки или дневные сводки. Например, вместо десяти отдельных писем отправить одно сообщение: «В вашем проекте появилось 10 новых комментариев».
Что такое группировка уведомлений
Группировка объединяет несколько связанных событий в одно сообщение. Например: Анна оставила комментарий Иван оставил комментарий Мария оставила комментарий Можно показать: В вашей задаче появилось 3 новых комментария Группировка уведомлений пользователя уменьшает информационный шум. Но объединять можно не всё. Сообщения о безопасности аккаунта или важных финансовых операциях обычно требуют отдельного подхода.
Как учитывать часовой пояс пользователя
Представим, что приложение отправляет ежедневную сводку в 9:00. Если использовать только время сервера, пользователи из разных регионов будут получать письма в неудобные часы. Поэтому отправка уведомлений по часовому поясу требует хранения предпочтений пользователя и корректной работы с датами.
Для серверного хранения времени обычно удобно использовать UTC, а локальное время рассчитывать с учётом выбранной временной зоны. При планировании регулярных отправок необходимо учитывать переходы на летнее и зимнее время там, где они применяются.
Что такое тихие часы
Пользователь может не хотеть получать необязательные уведомления ночью. Поэтому приложение может поддерживать настройку: Не беспокоить: 22:00–08:00 Тихие часы для уведомлений особенно полезны для push и других каналов, которые активно привлекают внимание. При этом некоторые сообщения, например о критических событиях безопасности, могут обрабатываться по отдельным правилам.
Важно заранее определить категории, на которые распространяются ограничения.
Как создать настройки уведомлений
В личном кабинете можно предложить пользователю управлять каналами. Например: Управление настройками уведомлений делает систему прозрачнее. При этом интерфейс должен объяснять, какие сообщения обязательны для работы сервиса, а какие можно отключить. Для маркетинговых рассылок нужно отдельно учитывать требования к согласию и отказу от получения сообщений.
Почему уведомления могут стать проблемой безопасности
Сообщения иногда содержат чувствительную информацию. Например, название конфиденциального документа, финансовые данные или сведения о действиях пользователя. Если такие данные отправлять в push, они могут появляться на заблокированном экране устройства. Поэтому безопасность уведомлений в веб-приложении включает не только защиту API, но и выбор содержимого сообщения.
Вместо подробного текста можно отправить нейтральное уведомление: «У вас готов новый результат. Откройте приложение для просмотра». Особенно это важно для медицинских, финансовых и корпоративных сервисов.
Почему нельзя доверять ссылкам из уведомлений
Представим, что пользователь нажимает на уведомление и переходит к документу. Backend всё равно должен проверить, имеет ли этот пользователь право открыть документ. Проверка доступа по ссылке из уведомления обязательна. Само наличие ссылки в уведомлении не является доказательством авторизации.
Кроме того, если target_url формируется из пользовательских данных, нужно ограничивать допустимые адреса и избегать небезопасных перенаправлений.
Как реализовать уведомления для AI-сервиса
Рассмотрим конкретный пример. Пользователь загружает документ для анализа. Backend сохраняет файл, создаёт фоновую задачу и возвращает идентификатор обработки. Worker выполняет анализ и сохраняет результат. После успешного завершения создаётся событие: document.analysis.completed Notification Service определяет получателя и его настройки.
Затем создаёт внутреннее уведомление и, при наличии разрешения, отправляет push. Так уведомления о завершении AI-задачи помогают пользователю не держать страницу открытой в течение всей обработки. Важно, чтобы уведомление создавалось только после фиксации готового результата.
Как реализовать уведомления об оплате
Другой пример — покупка подписки. Платёжный провайдер отправляет подтверждённое событие. Backend проверяет его подлинность и обновляет состояние заказа. После этого создаётся уведомление об успешной оплате. Уведомления об успешной оплате должны быть связаны с подтверждённой бизнес-операцией. Если Webhook приходит повторно, система не должна отправлять новое письмо о той же покупке без необходимости.
Также стоит разделять сообщение об успешном платеже и сообщение о предоставлении доступа, если эти действия выполняются на разных этапах.
Как тестировать систему уведомлений
Тестирование должно проверять не только отправку одного сообщения. Полезно убедиться, что уведомление создаётся для правильного пользователя, соответствует его настройкам и не дублируется при повторном событии. Отдельно проверяются ошибки провайдера, повторные попытки, недействительные push-подписки и доступ к чужим уведомлениям.
Тестирование системы уведомлений включает бизнес-логику, API, очередь доставки и взаимодействие с внешними сервисами. Для unit tests обычно используют подмены email- и push-клиентов, чтобы не отправлять настоящие сообщения при каждом запуске тестов.
Как проверить email-уведомления
В тестовой среде можно использовать специальный почтовый сервис или локальный SMTP-приёмник, который сохраняет письма без доставки реальным пользователям. Это позволяет проверить тему, адрес получателя, текст и ссылки. Тестирование email-уведомлений Python должно учитывать не только успешную отправку, но и некорректные адреса, ошибки подключения и отсутствие необходимых переменных окружения.
Не стоит использовать настоящие рабочие списки адресов в автоматических тестах.
Как мониторить уведомления
После запуска полезно отслеживать: Создано уведомлений Отправлено email Ошибки email Отправлено push Недействительные push-подписки Время ожидания в очереди Количество повторных попыток Мониторинг доставки уведомлений помогает обнаруживать проблемы, которые пользователь не всегда сообщает напрямую.
Например, если письма перестали отправляться из-за ошибки авторизации SMTP, приложение может продолжать нормально работать, но важные сообщения не будут доставляться. Поэтому ошибки каналов доставки должны быть видны разработчику.
Как масштабировать систему уведомлений
На старте приложение может отправлять десятки сообщений в день. Позже объём может вырасти до тысяч или миллионов событий. При этом архитектуру не обязательно полностью переписывать. Если уведомления уже отделены от бизнес-логики, можно постепенно увеличивать число workers, добавлять очереди по каналам и оптимизировать хранение истории.
Масштабирование сервиса уведомлений должно учитывать ограничения провайдеров, скорость отправки и требования к своевременности доставки. Не все каналы масштабируются одинаково: email, Web Push и обновления через WebSocket имеют разные характеристики.
Почему не нужно начинать с микросервисов
Начинающий разработчик может захотеть создать отдельный сервис для email, отдельный для push и ещё один для внутренних сообщений. Но для небольшого продукта это часто неоправданно сложно. Гораздо разумнее начать с модульной архитектуры внутри одного Backend. Например: app/ ├── notifications/ │ ├── models.py │ ├── repository.py │ ├── service.py │ ├── routes.py │ └── templates/ ├── email/ │ └── client.py └── push/
└── client.py Модуль уведомлений в Python Backend может быть достаточно самостоятельным без выделения в отдельный сервер. При необходимости его будет проще развивать, если ответственность компонентов определена заранее.
Частые ошибки при создании уведомлений
Первая ошибка — отправлять сообщения непосредственно из каждого обработчика бизнес-логики. Со временем код становится связанным и трудным для поддержки. Вторая — не сохранять историю внутренних уведомлений. Третья — не проверять, кому принадлежит уведомление, при чтении и изменении его состояния. Четвёртая — считать, что успешная отправка через API гарантирует доставку и прочтение.
Пятая — не учитывать повторные события и отправлять дубли. Шестая — запрашивать разрешение на push сразу после открытия сайта без объяснения пользы. Седьмая — отправлять слишком много сообщений и игнорировать пользовательские предпочтения. Восьмая — помещать конфиденциальные данные в push-уведомления. Девятая — не удалять недействительные push-подписки. Десятая — не мониторить ошибки доставки.
Эти ошибки реализации уведомлений на сайте могут привести не только к техническим проблемам, но и к потере доверия пользователей.
Чек-лист разработки уведомлений
Перед запуском полезно ответить на несколько вопросов. Какие события действительно требуют уведомления? Какие каналы подходят каждому событию? Где хранится история сообщений? Как пользователь управляет предпочтениями? Можно ли безопасно повторить обработку события?
Как система реагирует на ошибки email- или push-провайдера? Что произойдёт, если пользователь offline? Защищены ли API от чтения чужих уведомлений? Не содержат ли сообщения чувствительные данные? Отдельно стоит проверить, что уведомления создаются после успешного завершения соответствующей бизнес-операции.
Такой чек-лист системы уведомлений помогает построить функциональность, которая полезна пользователю и остаётся управляемой для разработчика.
FAQ
Можно создать таблицу уведомлений, API для получения и изменения их состояния, а также сервис, который реагирует на события приложения. Для email и push дополнительно понадобятся соответствующие каналы доставки.
Это зависит от задачи. Email подходит для подтверждений и подробных сообщений. Push полезен для оперативных уведомлений, если пользователь дал разрешение. Внутренние уведомления удобны для хранения истории событий. Да. FastAPI подходит для API внутренних уведомлений, обработки пользовательских настроек и интеграции с email- и push-сервисами.
Не обязательно. Для небольшого приложения может хватить базы данных и простого механизма фоновых задач. Redis или другой брокер становится полезным, когда нужна отдельная очередь доставки. Web Push предназначен для доставки уведомлений через браузерную push-инфраструктуру. WebSocket поддерживает активное соединение между клиентом и сервером и удобен для обновления открытого интерфейса.
Нет, обычные браузерные push-уведомления требуют соответствующего разрешения и поддержки со стороны браузера. Причина может быть в настройках SMTP, ошибке провайдера, неправильном адресе, отклонении сообщения или попадании письма в спам. Необходимо проверять журналы отправки и доступные статусы доставки.
Нужно связывать уведомления с уникальными бизнес-событиями и использовать ограничения базы данных. Дополнительно следует учитывать повторные попытки доставки через внешние сервисы. Нет. Срок хранения зависит от типа сообщения, требований продукта и применимых правил обработки данных.
Worker может сохранить результат, создать событие завершения, а сервис уведомлений — сформировать внутреннее сообщение и отправить push или email в соответствии с настройками пользователя.
Заключение
Система уведомлений помогает веб-приложению оставаться полезным даже тогда, когда пользователь не находится на нужной странице. Она сообщает о важных событиях, завершении долгих операций, изменениях аккаунта и взаимодействии с другими людьми. Но качественные уведомления требуют большего, чем вызов функции отправки email.
Разработчику нужно определить события продукта, выбрать подходящие каналы, сохранить историю сообщений, учесть пользовательские предпочтения и организовать надёжную доставку. Для небольшого приложения разумно начать с внутренних уведомлений и email. Web Push и real-time обновления можно добавлять тогда, когда они действительно улучшают пользовательский опыт.
Особенно важно отделять бизнес-события от способов доставки. Благодаря этому одна и та же операция может формировать разные уведомления без дублирования логики внутри Backend. Хорошая система уведомлений не пытается сообщать пользователю обо всём. Она помогает человеку вовремя узнать именно то, что для него важно.