I have a meteor app where users can follow a post (similar to watching a GitHub repository). Email notifications need to be sent out when there are updates or new comments. Since there is a potential need to send 1000’s of email throughout the day, I was wondering how other developers are handling this task.
There are a few ways to do it. Simply using the email package along with a mailgun account and MAIL_URL environment variable will get you going. What are your concerns?
I think Mailgun is made for this. It is even free for 10.000 mails every month. Worked for me without any hassles.
My concern is that the email load could get pretty high and I want to make sure there are no performance issues or pitfalls to watch out for. Mailgun looks good. I see there’s a meteor package.
Yeah, I’ve seen that package, but in all honesty, I find the default email package more than adequate. Set up your mailgun account, get your username and password, construct a MAIL_URL environment variable, and you should be set.
I think that out of the gate the only thing to watch out for is if you are waiting on callbacks to move the user experience along. But that’s something that needs to be evaluated on a case by case basis, I think. If it’s just email notifications that are being distributed when a new post/comment is created, that should all be happening in the background, on the server, so there should be no need to have a delay on the client side.
Depending on your server loads, you could also cron/schedule those emails, but that seems like overkill right off the bat?
Sounds like a good start. Would I have a Meteor method on the server only and then just call it from the client? Does Meteor have a server side thread pool? Sorry for all the questions, but I’m just trying to figure out the best practices. Thanks.
I think it all depends on your use case. A basic implementation would yes, use a method on the server that is triggered on a client action (like creating a post). Your method could run through a loop, shooting off the emails one by one. Or, you could create a digest of posts that could be cronned later?
It’s hard to say what a ‘best practice’ would be without knowing the exact case. If I were in your shoes, I’d focus on getting the emails sent right now and cross the 1000s of emails a day bridge when I got to it.
I’ve sent emails at larger than normal scale (around 70,000) and found that you need to use their API’s at that scale.
Use whatever templating your email SaaS supports (handlebars, replacement tags, etc) and fire off API requests.
Bad
- Your app generates the email
- Send it out using SMTP credentials
Good
- Your app generates payload (json, whatever)
- You send your payload to your email SaaS through API.
- Your SaaS is the one doing the heavy lifting (sending out emails).
Using this we’ve gone down from a 23 hour email sending timeframe to about 21 minutes. We could speed it up a bit but the takeaway here is:
Use templating. Don’t send emails out yourself.
Honestly, long term this is the better approach, and forgive me for putting on my “cart before the horse” shoes too quickly.
I’m too often in mvp mode, where demonstrating functionality/proof of concept is at the forefront of my mind.
Kudos to @sergiotapia for this post!
2 Likes
Oh yeah, I wasn’t really responding to anyone sorry. I didn’t mean to discredit anyone, just read the OP and wanted to help out. 
I would recommend SendGrid because their documentation is the better out of Mandrill, SendGrid and Mailgun. (I tried all three…)
Thanks, SendGrid looks great and their Transactional Templates is a great fit. Also, the free plan is a plus.
I’m using Amazon SES and Meteor’s native Email.send method to send out single emails. But the requirement to send out bulk emails (maybe 150 at a time) as come up recently. Has anyone used Amazon’s SES to send out bulk emails? Could I still use the native Email.send to send bulk emails?
I think there is a discussion going on here
And this is my thread here, I wanted the same thing
https://forums.meteor.com/t/best-practices-when-sending-a-million-emails?source_topic_id=15946