Repository navigation
Releases: abdiu34567/queue-notifier
Release list
Release Notes - v1.9.0
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
- Structured Logging with Pino:
- Replaced the previous simple logger with
pinofor 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 theLOG_LEVELenvironment variable (infodefault). - Added
pino-prettyas an optional dev dependency for improved readability during development.
- Replaced the previous simple logger with
- Refactored Worker Management:
- Removed
startWorker: truefromdispatchNotifications: This breaking change promotes the standard architecture of separating job producers and consumers. Users must now run workers independently usingstartWorkerServer. (#XXX) - Added
WorkerManager.pauseProcessing()andWorkerManager.resumeProcessing()methods to allow operators to gracefully pause/resume job consumption from a queue. (#XXX) - The existing
WorkerManager.close()method provides graceful shutdown.
- Removed
- Campaign Cancellation:
- Added optional
campaignIdtodispatchNotifications. (#XXX) - Workers now check for a Redis key (
worker:cancel:campaign:<campaignId>) before processing jobs with a matchingcampaignId. Setting the key's value to'true'will cause workers to skip processing for that campaign gracefully. - Removed the previous global
SimulationManagerin favor of this more targeted cancellation mechanism.
- Added optional
- Simplified Dispatch Configuration:
- Removed
notifierOptionsandcustomNotifierfromdispatchNotifications. Notifier configuration is now solely handled bystartWorkerServer. (#XXX) - Renamed
notifierTypetochannelNameindispatchNotificationsfor clarity. Kept generic type link formetasafety.
- Removed
- Refactored Notifier Implementation:
- Notifiers (
EmailNotifier,FirebaseNotifier, etc.) now delegate batching/concurrency/rate-limiting to a sharedbatchSenderutility internally. (#XXX) - Notifier
sendmethods now accept aPinoLoggerinstance for contextual logging during message sending.
- Notifiers (
- Improved Redis Instance Handling (
ensureRedisInstance):- The helper now robustly validates provided
ioredisinstances or creates new ones, ensuring required BullMQ options (maxRetriesPerRequest: null) are set correctly. (#XXX) - Provides clearer warnings and errors for misconfigured instances.
- The helper now robustly validates provided
- Firebase Notifier Configuration:
startWorkerServerconfiguration for Firebase (notifiers.firebase) now accepts theServiceAccountobject or a file path string directly, removing the need for the{ serviceAccount: ... }wrapper. (#XXX)
💥 Breaking Changes
startWorker: trueRemoved: ThestartWorkeroption indispatchNotificationshas been removed. Users must run worker processes separately usingstartWorkerServer. Update your deployment strategy accordingly.dispatchNotificationsConfiguration:notifierOptionsparameter removed. Configure notifiers viastartWorkerServer.customNotifierparameter removed. Register custom notifiers manually viaNotifierRegistryin your worker process.notifierTyperenamed tochannelName.
SimulationManagerRemoved: The global simulation mode managed viaSimulationManagerand Redis keyworker:simulation_modehas been removed. Use targeted Campaign Cancellation or environment variables for testing/simulation needs.- Notifier
sendSignature: Thesendmethod on theNotificationChannelinterface (and all implementing classes) now requires aPinoLoggerinstance as the third argument. If you have custom notifiers, update their signatures. - Firebase Config: The structure for configuring Firebase in
startWorkerServerhas changed fromnotifiers: { firebase: { serviceAccount: ... } }tonotifiers: { firebase: serviceAccountOrPathString }.
🔧 Minor Changes & Fixes
- Improved type safety in various interfaces (
NotificationResult, Meta types). - Refined error formatting in notifier results.
- Standardized use of
RateLimiteracross 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
pinoas a direct dependency. - Updated BullMQ / ioredis / Notifier SDK types where applicable (List specific versions if changed significantly).
📝 Migration Guide
- Remove
startWorker: true: Delete thestartWorkeroption from alldispatchNotificationscalls. - Create Worker Script: Set up a separate Node.js script using
startWorkerServerto run your worker processes. Configure all necessary notifiers within thenotifiersoption ofstartWorkerServer. Deploy and manage this script using a process manager (PM2, nodemon, Docker, etc.). - Update
dispatchNotificationsCalls:- Rename
notifierTypetochannelName. - Remove
notifierOptions. - Remove
customNotifier. - (Optional) Add
campaignIdif you need cancellation capabilities.
- Rename
- Update
startWorkerServerConfig: If using Firebase, update thenotifiers.firebasevalue to pass the service account object or path directly. - Update Custom Notifiers: If you have custom classes implementing
NotificationChannel, update theirsendmethod to acceptlogger: PinoLoggeras the third argument. - Review Logging: Adapt to the new
pinobased logging output. Configure log levels viaLOG_LEVELenv var orloggerFactory.setLevel(). Consider usingpino-prettyin development. - Update Redis Instance Creation: If providing your own
ioredisinstance, ensure it's created withmaxRetriesPerRequest: null.
How to Use:
See the updated README.md for detailed usage instructions and examples.
v1.1.0
🚀 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@latestThen 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
🚀 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@latestThen 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! 💻🚀