Amazon SES

Amazon SES

Utilities / Communications / Transactional Email
Needs advice
on
Amazon SESAmazon SES
and
MailchimpMailchimp
in

I would like to know how I can implement a transactional email, or if it is possible to do so, like Mailchimp, using Amazon SES. I want to have the flexibility of creating emails like MailChimp, with a bulk email sending capability. Is it as simple with AWS SES as it is with MailChimp? If so, then how can I implement that for my own product? Thanks!

READ MORE
6 upvotes·65K views
Replies (2)
Full Stack Product Designer at Serif & Semaphore·
Recommends
on
Sendgrid

I'd look at SendGrid for bulk and transactional emails. They have a template system where you upload/save templates on their end that you refer to when you use their API. You then pass an object with key/value pairs for replacements in the template. I believe they are handlebars templates. Anyway, you can send in bulk this way.

It will be far cheaper to DIY with AWS SES, but you have to code quite a bit yourself. You may want to look if there's any open source project that helps here. I'm not aware of any, I'd have to Google it.

One downside of SendGrid is that testing things is difficult. They have a "sandbox" that will tell you if the API request is correct, but it's a bit useless. It doesn't let you see if your email looks correct and that the data was replaced correctly. So if as you code and test you're going to be sending real emails. Less than ideal for a QA team. I wish SendGrid had a Mailtrap type feature. Then you can send to any email address you like and just have it land in a fake email bin that you can share with your team. To me, this is a critical feature SendGrid is missing. Other than that, I've been happy with SendGrid. A little pricey I think, but they do a great job retrying to send email, adding emails to a suppression list, etc. Again, all nice features you'd be on the hook for building if you went with something custom with SES. So factor in time savings and SendGrid has great value. Long term and depending on your volume, that may be a different story.

READ MORE
5 upvotes·4.4K views
CEO, lead developer at Localazy·

Mailchimp is more user-oriented while Amazon SES is a cheaper solution more suitable for being an SMTP server. If you need to send occasional emails manually, go with Mailchimp or another provider. If you want to send transactional emails from your app, Amazon SES is the best choice.

READ MORE
1 upvote·4.1K views
Managing Director at Bettison.org Limited·
Shared insights
at

In 2012 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.

Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.

PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.

Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!

Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.

We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).

Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service

READ MORE
8 upvotes·754.2K views