Seems like retries and delays are not part of this, but I guess they are added easily enough to the individual queue system used. Any desire to build them into it? Retries should be easy enough if you're happy to modify the bodies, although delays are not so easy (we're using the 'delayed message exchange' plugin for Rabbit to do this currently).
Maybe some built-in/example queue integrations (Rabbit, Redis, etc)?
Also, it's not super clear to me how you might host the SMS/Push/email/whatever provider on a different process/system to the publisher?
Very nice, queue integration examples are one of my next steps. I didn't include the queue inside the lib to give the choice to users, but I intended to write a few ones. Would you want code one? About the consumer, it's running on the same instance than the producer for more simplicity (but you can always run instances that only do consumer job).
Thanks for the feedback. I added the word "transactional" to say that we can't send batches with the lib. Anyway it's not a hard limitation because you can always make a loop.
Shameless plug here.. I've been working on a service that kinda solves a similar problem, called Postways [1].
Even though Postways also provides a unified API for sending email, SMS and mobile push, the main focus of Postways is actually on managing the message templates. When you work with a team where not everyone is a developer, updating the actual message text can be a major problem, especially when the message text is in source code or various different places.
Hi hitgeek, thanks for your comment.
The backstory is quite simple, the initial plan was to make a saas api service, but we don't like cold calling so much, so it ended up as an open source project :)
I've used https://github.com/kelektiv/node-cron in the past, which could be run in the same process as the web app or in its own process. Works really well for recurring jobs.
fallback + round-robin : <3
Awesome idea.
fallback : could be very usefull if you main provider is down
round-robin : send more free emails using multiple providers
Seems like retries and delays are not part of this, but I guess they are added easily enough to the individual queue system used. Any desire to build them into it? Retries should be easy enough if you're happy to modify the bodies, although delays are not so easy (we're using the 'delayed message exchange' plugin for Rabbit to do this currently).
Maybe some built-in/example queue integrations (Rabbit, Redis, etc)?
Also, it's not super clear to me how you might host the SMS/Push/email/whatever provider on a different process/system to the publisher?
But it looks lovely and clean! Major props!