6 ms·
can you elaborate more? show a driver in code? what do you mean by it exactly. I was not happy with Mandrill's decision but can't complain since it was free. I
by jorgecurio 11y ago
can you elaborate more? show a driver in code? what do you mean by it exactly.
I was not happy with Mandrill's decision but can't complain since it was free. I'm moving to amazon email services.
I think case in point, free is not forever in SaaS business.
- tomschlick 11y agoSure! A great example is the actual code we are using now. We are based on the Laravel framework so here is the driver code laravel uses. https://github.com/laravel/framework/tree/5.2/src/Illuminate/Mail/Transport https://github.com/laravel/framework/tree/5.2/src/Illuminate... You'll notice there is an abstract class "Transport.php" which declares certain methods (via the Swift_Transport interface class) that the "MandrillTransport", "MailgunTransport" and the "SesTransport" must all implement. > I think case in point, free is not forever in SaaS business. Our account & our customers' accounts were all paid. Some of them send up to 500,000 emails each per month. I would have been fine with them getting rid of the free tier, its the TOS change for marketing emails that killed our use with them.
- deleted 11y ago[deleted]
- AznHisoka 11y agoI think OP is making it more complicated than it really is. Just abstract the logic as much as possible, confining it into 1 place. For instance, just have a class EmailSender with the method "sendEmail", and have all your clients call this class whenever they need to send an email Now if you moved to SES from Mandrill, you just change it in 1 place. It's not rocket science or voodoo.
- tomschlick 11y agoThats true. I use abstraction a little further because we have the need for multiple email providers at once. But there is nothing wrong with doing it the way you described.
- gingerlime 11y agoOr isn't SMTP the universal driver / adapter in this case? Which all those email providers support as far as I know. Then you don't even change the code, but just configuration. APIs are great, but I'd say protocols (or at least the well adopted ones) are better.
- tomschlick 11y agoSMTP is also 3-10x slower than a simple POST request though. If you're sending 10,000 emails an hour that adds up.
- icebraining 11y agoWhy is SMTP slower? You can open a connection, authenticate and then send as many emails as you want. Doesn't seem slower than sending POST requests with their headers and such.
- tomschlick 11y agoIn theory yes, in practice that's usually not the case in my experience.
- deleted 11y ago[deleted]
- baudehlo 11y agoThe technical answer is it's complicated. SMTP is chatty. Even when you use PIPELINING. It tends to send way more packets than HTTP. And while you can open one connection and send multiple mails through it, the likelihood of your client library doing that is pretty low, sadly.
- tracker1 11y agoSMTP must maintain a transient state throughout the connection and respond to interactive requests... HTTP-POST can handle the request chain inline, and deliver a single response, the decision tree is much lighter. For that matter, HTTP-POST can partially to completely defer all processing decision trees, always returning 200 OK, offloading to a queue system that will process the request out of band, and issue the real response errors via a dashboard. Making it lighter still.
- ignoramous 11y agoDependency Inversion Principle is more apt a term, I think: http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important http://stackoverflow.com/questions/62539/what-is-the-depende... https://en.wikipedia.org/wiki/Dependency_inversion_principle https://en.wikipedia.org/wiki/Dependency_inversion_principle