4 ms·

I 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 cl

I 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 ago
Thats 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 ago
Or 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 ago
  SMTP 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 ago
    Why 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 ago
      In theory yes, in practice that's usually not the case in my experience.
    - deleted 11y ago
      [deleted]
    - baudehlo 11y ago
      The 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 ago
      SMTP 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.

tomschlick 11y ago

Thats 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 ago

Or 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 ago
SMTP 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 ago
  Why 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 ago
    In theory yes, in practice that's usually not the case in my experience.
  - deleted 11y ago
    [deleted]
  - baudehlo 11y ago
    The 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 ago
    SMTP 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.