search

geeklearningio / gl-dotnet-email

.NET Core Email abstractions with SendGrid, SMTP and InMemory providers
MIT License
5 stars 3 forks source link

Discussion : Does it makes sense to support alternative providers #16

Open sandorfr opened 7 years ago

sandorfr commented 7 years ago

I don't think we should provide too many provider out of the box as it will slow our capability to provide new features. Instead we should rely on the community to bring that support. In addition, most providers have an smtp api, so our smtp provider can be used as a fallback.

That said, if we want to extend the feature coverage of our abstraction, this might make sense to have 2-3 commercial alternatives. We should select them based on Quality Of Server, Features and Market Share. This article provides a few insights.

sandorfr commented 7 years ago

Amazon SES would be my prime candidate. SparkPost would come next.

asiffermann commented 7 years ago

I'm not sure if it's really necessary to support alternative providers right now, unless one of us do have the specific need.

Alternative providers would be great for our library's notoriety, but before that we should complete the other issues (CC, BCC, Reply-To), create the documentation and write unit and integration tests.

Once we have done that, hopefully someone would ask or contribute to add other providers. Or, we could choose the most trending one :)

sandorfr commented 6 years ago

MailJet (available on azure marketplace) might be worth considering.

asiffermann commented 6 years ago

A SendinBlue provider would interest me too.