8 ms·

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 so

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.

merlincorey 11y ago
Is "driver" the new name for "adapter pattern"?
- tomschlick 11y ago
  Adapter is probably a better word for it. Driver just tends to be common nomenclature.
  - seanp2k2 11y ago
    I guess I still just associate "driver" with an INF file that you right-click -> install to make some hardware work in Windows.
    - tomschlick 11y ago
      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).
- dragonwriter 11y ago
  > 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.
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 ago
  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/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 ago
  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.
  - 11y ago
mtberatwork 11y ago
"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?
- tomschlick 11y ago
  No. Mandrill allowed for marketing emails as well. Mailchimp is much more expensive and our clients wouldn't be using their interface anyway.
jgalt212 11y ago
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.
jfroma 11y ago
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.

merlincorey 11y ago

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

tomschlick 11y ago
Adapter is probably a better word for it. Driver just tends to be common nomenclature.
- seanp2k2 11y ago
  I guess I still just associate "driver" with an INF file that you right-click -> install to make some hardware work in Windows.
  - tomschlick 11y ago
    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).
dragonwriter 11y ago
> 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.

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 ago
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/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 ago
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.
- 11y ago

mtberatwork 11y ago

"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?

tomschlick 11y ago
No. Mandrill allowed for marketing emails as well. Mailchimp is much more expensive and our clients wouldn't be using their interface anyway.

jgalt212 11y ago

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.

jfroma 11y ago

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.