3 ms·

That's pretty nifty, and a good idea. You probably should look at using sqlite or even json to persist future follow ups... It's lost on restart at the moment?

• sssaini 6y ago
  Hey keyle, your points are right on the money. 1. sqlite is a great idea for persistence. It would be an in-memory db right? 2. There is a stop method already. I should do a better job of highlighting that in the README. But you can stop all messages from being sent out by: mailcandy.stop() or you can clear all the upcoming messages while keeping the timer going by: mailcandy.clearAllScheduledMessages() 3. Added to backlog. Are there any mail servers you would like to see?
  • dceddia 6y ago
    SQLite does have an in-memory option but you don’t want to use that here, otherwise it won’t actually be persistent. It’d get destroyed when the app restarts. You want SQLite to persist to a file. I think OP meant stop as in “unsubscribe”. Ability to unsubscribe is required by law in a lot of places, I’d definitely want to have that in place. This kind of use case falls under “transactional email” and there are lots of providers you can use for that. Mailgun, AWS SES, Postmark, Sendgrid, and a ton of others. They’re purpose-built for sending one-off emails like this.
    • sssaini 6y ago
      Ahh thank you for the clarification @dceddia. 1. Yep that makes perfect sense. A persisted file keeps the data and the SqLite provides an easy interface to work with. 2. I mistakenly thought it wasn't important. But I've moved it to the top of the backlog, should be available soon. 3. This is gold. Looked into transactional emails and that's exactly what's needed. Moreover, there's projects like nodemailer-mailgun-transport that will make this easier. Cheers!