Skip to content

Releases: abdiu34567/queue-notifier

Release Notes - v1.9.0

Choose a tag to compare

@abdiu34567 abdiu34567 released this 24 Apr 11:58

Release Notes - v1.9.0

This release introduces significant improvements to logging, configuration, worker management, and adds new features like campaign cancellation, focusing on robustness, developer experience, and alignment with best practices.

✨ New Features & Major Improvements

  1. Structured Logging with Pino:
    • Replaced the previous simple logger with pino for fast, structured (JSON) logging. (#XXX)
    • Logs now include rich context (component, queue, job ID, campaign ID, etc.).
    • Log level is configurable via loggerFactory.setLevel() or the LOG_LEVEL environment variable (info default).
    • Added pino-pretty as an optional dev dependency for improved readability during development.
  2. Refactored Worker Management:
    • Removed startWorker: true from dispatchNotifications: This breaking change promotes the standard architecture of separating job producers and consumers. Users must now run workers independently using startWorkerServer. (#XXX)
    • Added WorkerManager.pauseProcessing() and WorkerManager.resumeProcessing() methods to allow operators to gracefully pause/resume job consumption from a queue. (#XXX)
    • The existing WorkerManager.close() method provides graceful shutdown.
  3. Campaign Cancellation:
    • Added optional campaignId to dispatchNotifications. (#XXX)
    • Workers now check for a Redis key (worker:cancel:campaign:<campaignId>) before processing jobs with a matching campaignId. Setting the key's value to 'true' will cause workers to skip processing for that campaign gracefully.
    • Removed the previous global SimulationManager in favor of this more targeted cancellation mechanism.
  4. Simplified Dispatch Configuration:
    • Removed notifierOptions and customNotifier from dispatchNotifications. Notifier configuration is now solely handled by startWorkerServer. (#XXX)
    • Renamed notifierType to channelName in dispatchNotifications for clarity. Kept generic type link for meta safety.
  5. Refactored Notifier Implementation:
    • Notifiers (EmailNotifier, FirebaseNotifier, etc.) now delegate batching/concurrency/rate-limiting to a shared batchSender utility internally. (#XXX)
    • Notifier send methods now accept a PinoLogger instance for contextual logging during message sending.
  6. Improved Redis Instance Handling (ensureRedisInstance):
    • The helper now robustly validates provided ioredis instances or creates new ones, ensuring required BullMQ options (maxRetriesPerRequest: null) are set correctly. (#XXX)
    • Provides clearer warnings and errors for misconfigured instances.
  7. Firebase Notifier Configuration:
    • startWorkerServer configuration for Firebase (notifiers.firebase) now accepts the ServiceAccount object or a file path string directly, removing the need for the { serviceAccount: ... } wrapper. (#XXX)

💥 Breaking Changes

  • startWorker: true Removed: The startWorker option in dispatchNotifications has been removed. Users must run worker processes separately using startWorkerServer. Update your deployment strategy accordingly.
  • dispatchNotifications Configuration:
    • notifierOptions parameter removed. Configure notifiers via startWorkerServer.
    • customNotifier parameter removed. Register custom notifiers manually via NotifierRegistry in your worker process.
    • notifierType renamed to channelName.
  • SimulationManager Removed: The global simulation mode managed via SimulationManager and Redis key worker:simulation_mode has been removed. Use targeted Campaign Cancellation or environment variables for testing/simulation needs.
  • Notifier send Signature: The send method on the NotificationChannel interface (and all implementing classes) now requires a PinoLogger instance as the third argument. If you have custom notifiers, update their signatures.
  • Firebase Config: The structure for configuring Firebase in startWorkerServer has changed from notifiers: { firebase: { serviceAccount: ... } } to notifiers: { firebase: serviceAccountOrPathString }.

🔧 Minor Changes & Fixes

  • Improved type safety in various interfaces (NotificationResult, Meta types).
  • Refined error formatting in notifier results.
  • Standardized use of RateLimiter across notifiers.
  • Added comprehensive unit tests for core utilities and notifiers (focusing on functionality). (#XXX)
  • Updated README with new architecture, configuration, and examples. (#XXX)

⬆️ Dependency Updates

  • Added pino as a direct dependency.
  • Updated BullMQ / ioredis / Notifier SDK types where applicable (List specific versions if changed significantly).

📝 Migration Guide

  1. Remove startWorker: true: Delete the startWorker option from all dispatchNotifications calls.
  2. Create Worker Script: Set up a separate Node.js script using startWorkerServer to run your worker processes. Configure all necessary notifiers within the notifiers option of startWorkerServer. Deploy and manage this script using a process manager (PM2, nodemon, Docker, etc.).
  3. Update dispatchNotifications Calls:
    • Rename notifierType to channelName.
    • Remove notifierOptions.
    • Remove customNotifier.
    • (Optional) Add campaignId if you need cancellation capabilities.
  4. Update startWorkerServer Config: If using Firebase, update the notifiers.firebase value to pass the service account object or path directly.
  5. Update Custom Notifiers: If you have custom classes implementing NotificationChannel, update their send method to accept logger: PinoLogger as the third argument.
  6. Review Logging: Adapt to the new pino based logging output. Configure log levels via LOG_LEVEL env var or loggerFactory.setLevel(). Consider using pino-pretty in development.
  7. Update Redis Instance Creation: If providing your own ioredis instance, ensure it's created with maxRetriesPerRequest: null.

How to Use:

See the updated README.md for detailed usage instructions and examples.

v1.1.0

Choose a tag to compare

@abdiu34567 abdiu34567 released this 18 Mar 07:55

🚀 Notify Worker SDK v1.1.0

📢 Notify Worker SDK v1.1.0 is here! 🎉
This release brings a major enhancement by introducing startWorkerServer, a streamlined way to initialize workers for processing queued notifications. Now, setting up a worker server is simpler, cleaner, and more efficient than ever before!


📦 What's New in v1.1.0?

1️⃣ New Feature: startWorkerServer() 🚀

✅ Easier Worker Initialization → Quickly start a worker in a single function call.
✅ Supports Multi-Channel Notifiers → Register Firebase, Telegram, Email, Web Push, or custom notifiers with ease.
✅ Batch & Rate-Limiting Support → Automatically processes notifications efficiently.
✅ Completion & Drain Events → Now, workers can trigger custom actions when jobs complete or queues are fully drained.


2️⃣ Simplified Worker Setup with startWorkerServer()

Previously, users had to manually initialize a worker, configure Redis, and register notifiers. Now, it's as simple as:

📌 Before (Manual Worker Setup)

import Redis from "ioredis";
import { RedisClient, NotifierRegistry, TelegramNotifier, WorkerManager } from "notify-worker-sdk";

const redis = new Redis("redis://localhost:6379");
RedisClient.setInstance(redis);
NotifierRegistry.register("telegram", new TelegramNotifier({ botToken: process.env.BOT_TOKEN as string }));

new WorkerManager({ queueName: "notifications", concurrency: 20 });
console.log("Worker started.");

✅ Now (Using startWorkerServer())

import Redis from "ioredis";
import { startWorkerServer } from "notify-worker-sdk";

const redis = new Redis("redis://localhost:6379");

startWorkerServer({
  redisInstance: redis,
  queueName: "notifications",
  concurrency: 20,
  notifiers: {
    telegram: { botToken: process.env.BOT_TOKEN as string },
  },
  onComplete: async (job, stats) => {
    console.log(`✅ Job ${job.id} completed. Stats:`, stats);
  },
  onDrained: async () => {
    console.log("🔥 All jobs processed, queue is empty!");
  },
  resetStatsAfterCompletion: true, // Optionally reset stats after all jobs are done
});

✅ One-liner Worker Initialization! 🚀


3️⃣ Enhancements & Optimizations

⚡ Added onComplete Hook → Run custom logic after each job completes.
⚡ Added onDrained Hook → Get notified when all jobs in the queue are finished.
⚡ Supports Auto Stats Reset → Automatically clear tracking stats after processing.
⚡ Improved Error Handling → More detailed logs and stability improvements.


4️⃣ How to Upgrade

If you're upgrading from an earlier version:

npm install queue-notifier@latest

Then update your worker startup scripts to use the new startWorkerServer() function.


📚 Documentation

📖 Full documentation is available in the README.md.


🙌 Acknowledgments

A huge thank you to the community for feedback and contributions! 🎉

🔥 Excited for v1.1.0? Give us a ⭐ on GitHub. 🚀
📩 Found an issue? Report it on the GitHub Issues Page.


🚀 v1.1.0 is live! Now launching worker servers is easier than ever! 🎉

Happy coding! 💻🚀

v1.0.0

Choose a tag to compare

@abdiu34567 abdiu34567 released this 17 Mar 07:01

🚀 Release Notes: Notify Worker SDK v1.0.0

📢 Notify Worker SDK v1.0.0 is here! 🎉
This is the first stable release of the Notify Worker SDK, designed to simplify multi-channel notification dispatching using Redis-backed job queues.

🔹 Fully supports:
✅ Firebase (Push Notifications)
✅ Telegram Bot Messaging
✅ Email (via SMTP)
✅ Web Push Notifications


📦 What's New in v1.0.0?

1️⃣ Core Features

🔹 Multi-Channel Notification Support → Send notifications via Firebase, Telegram, Email, and Web Push.
🔹 Redis-Powered Job Queueing → Uses BullMQ for scalable notification handling.
🔹 Batch Processing & Rate Limiting → Efficiently process thousands of notifications per batch.
🔹 Response Tracking → Optionally store success/error stats in Redis for analytics.
🔹 Configurable Logging → Enable/disable logging based on environment needs.
🔹 Custom Notifier Support → Extend functionality by implementing your own notification channel.


2️⃣ Key Improvements & Optimizations

⚡ Improved Error Handling

  • Added exponential backoff retry for transient failures in database queries & notifications.
  • Errors are now explicitly logged for better debugging.

⚡ Optimized Rate Limiting

  • Introduced a Token Bucket Rate Limiter for smoother database & API rate control.
  • Prevents API throttling issues when dispatching notifications at scale.

⚡ Refactored Notification Notifiers
✅ Firebase Notifier: Now properly supports per-user metadata, ensuring unique push messages per recipient.
✅ Email Notifier: Optimized SMTP handling with rate control & enhanced error logging.
✅ Telegram Notifier: Improved message formatting and API reliability.
✅ Web Push Notifier: Fixed missing metadata issues, improved concurrency & VAPID handling.


3️⃣ Simplified API for Starting Workers

import Redis from "ioredis";
import { startWorkerServer } from "notify-worker-sdk";

const redis = new Redis("redis://localhost:6379");
startWorkerServer({
  redisInstance: redis,
  queueName: "notifications",
  concurrency: 20,
  notifiers: {
    telegram: { botToken: process.env.BOT_TOKEN as string },
  },
});

✅ One-liner Worker Initialization! 🚀


🔧 How to Upgrade

If you're upgrading from an earlier version:

npm install queue-notifier@latest

Then update your worker startup scripts to use the new simplified API.


📚 Documentation

📖 Full documentation available in the README.md.


🙌 Acknowledgments

A big thank you to everyone who contributed through testing, feedback, and PRs! 🎉

🔥 Excited for v1.0.0? Please give the repo a ⭐ on GitHub. 🚀
📩 Found an issue? Report it on the GitHub Issues Page.


🚀 v1.0.0 is live! Let’s scale notifications like never before! 🎉

Happy coding! 💻🚀