Comment by tomschlick | Hacker News Reader

Comment by tomschlick | Hacker News Reader

Parent Full thread

The struggle that many people have with API based providers is that they don't abstract that functionality in their application to a driver based system. For something as crucial as mail, payments, sms, etc you absolutely need to build it as if the provider could go away at any point.

Case in point: Mandrill announced two days ago that they were going to merge their product with MailChimp which included a terms of service change that banned marketing emails from Mandrill after their forced migration date in April. At work we have a commercial real estate app which lets our customers send marketing emails. We had built this functionality on top of mandrill but using a driver based system. Last night I launched a Mailgun driver and we have already started to migrate customers with their own Mandrill accounts to MG. If we hadn't used a driver based system we would be screwed for the next few weeks.

Build your api integrations via drivers. Even if you only have one driver. You will be happy you did later.

Is "driver" the new name for "adapter pattern"?

> Is "driver" the new name for "adapter pattern"?

Both "driver" and "adapter" as terms for instances of what has gotten labeled the "adapter pattern" were around before the architectural idea of design patterns was applied to software, so its not a new name for it.

Adapter is probably a better word for it. Driver just tends to be common nomenclature.

I guess I still just associate "driver" with an INF file that you right-click -> install to make some hardware work in Windows.

Same principal though. You have that driver to connect your internal code (Windows) to a third party service (Some shitty HP printer that you'll want to hit with a bat in 5 minutes).

"which lets our customers send marketing emails."

Shouldn't you have been using MailChimp all along? Mandrill is for transactional email messages (e.g. password resets, order receipts, etc). Did they ever allow bulk marketing messages through Mandrill?

No. Mandrill allowed for marketing emails as well.

Mailchimp is much more expensive and our clients wouldn't be using their interface anyway.

Yeah, that was quite a bait and switch there from mandrill. Very disappointed in them certainly when you consider that mailchimp templates integrated into Mandrill are pretty much purpose-built for marketing emails.

I am moving away from mandrill for other reasons but luckily I only have to change configuration. We used nodemailer which is node lib abstracting many mail providers, smtp, aws ses, mandrill, sendgrid, etc.

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.

Sure! 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...

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.

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.

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.

SMTP is also 3-10x slower than a simple POST request though. If you're sending 10,000 emails an hour that adds up.

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.

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.

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.

In theory yes, in practice that's usually not the case in my experience.

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.

Dependency Inversion Principle is more apt a term, I think: http://stackoverflow.com/questions/62539/what-is-the-depende...

https://en.wikipedia.org/wiki/Dependency_inversion_principle

Reply on news.ycombinator.com