Розробка системи сповіщень часто здається простою справою, проте реальні виклики виникають при роботі з нестабільними мережами, неактивними токенами пристроїв або налаштуваннями користувачів. Команда MotionLab вирішила відмовитися від складних інфраструктурних рішень на користь використання бази даних Postgres як центрального елемента черги. Цей підхід дозволяє уникнути розгортання окремого парку воркерів, використовуючи лише Next.js та Supabase для керування життєвим циклом повідомлень.
Основою системи є таблиця, де кожен рядок представляє окреме сповіщення. Стовпчик статусу діє як кінцевий автомат, переходячи між станами: pending, sent, delivered, retrying або dead. Використання часткових індексів у Postgres дозволяє ефективно відстежувати лише ті записи, які потребують обробки, ігноруючи вже завершені завдання. Це забезпечує високу продуктивність навіть при накопиченні великої кількості історичних даних, оскільки індекс залишається компактним і швидким.
Важливим етапом є перевірка вподобань користувача перед створенням запису. Функція enqueue() аналізує налаштування, щоб уникнути надсилання небажаного контенту, наприклад, маркетингових повідомлень, якщо користувач відмовився від них. Завдяки тому, що значення за замовчуванням визначені безпосередньо в схемі бази даних, система залишається гнучкою та надійною, а логіка відмови від розсилки працює автоматично без необхідності додаткових перевірок у коді застосунку.
Процес надсилання реалізований через інтерфейс NotificationChannel, що дозволяє легко додавати нові канали, такі як Email або SMS, у майбутньому. Для push-повідомлень використовується Firebase Admin SDK, який надає детальні результати для кожного токена. Це дозволяє системі автоматично деактивувати застарілі або недійсні токени, підтримуючи чистоту бази даних. Успіхом вважається доставка повідомлення хоча б на один пристрій користувача, що мінімізує зайві повторні спроби.
Механізм повторних спроб базується на виконанні запланованих завдань через Vercel Cron. Замість того, щоб використовувати таймери, система просто робить записи доступними для обробки після певного часу. Це спрощує архітектуру, оскільки логіка відкладеного виконання інтегрована безпосередньо в запити до бази даних. Такий підхід гарантує, що навіть у разі тимчасових збоїв FCM, повідомлення будуть надійно доставлені після відновлення сервісу.
Безпека та аналітика реалізовані через спеціальні функції Postgres, які дозволяють клієнтам оновлювати статуси доставки без прямого доступу до таблиць. Використання SECURITY DEFINER функцій забезпечує контроль над тим, які дані може змінювати користувач. Крім того, збір подій в окрему таблицю дозволяє легко аналізувати ефективність розсилок за допомогою SQL-запитів, що робить систему прозорою та зручною для подальшого масштабування та оптимізації продукту.
🔗 Першоджерело: Читати оригінал