Add Support for SES V2

[akefirad]

Type: Feature

Is your feature request related to a problem? Please describe.
There's a new SES API, version 2. It would be nice to have this support as well.

Happy to help with a PR.

[maciejwalkowiak]

Can you describe in more details what functionality do you have in mind?

[akefirad]

So there's a new SDK for SES API V2 which provides more functionalities (including more policy statement conditions). Here's a some examples from AWS. Does that help?

[maciejwalkowiak]

I'm still not sure how this will affect the functionality offered by Spring Cloud AWS, or is it more about autoconfiguring the client? Feel free to drop a PR perhaps it gets more clear then

[akefirad]

Imagine if I want to use version 2 (because of some specific feature available only in version 2) of SES client, I cannot use AWSpring SES module since this module is written on top of SES version 1 and won't work with version 2. Does that make sense? As for the PR, the question before attempting is how we want to support it? Duplicate the whole library? Or introduce an interface that abstract away the details of SES clients, V1 and V2. Or any other solution.

[maciejwalkowiak]

I see this making sense if we just drop SES v1 and replace it with SES v2. Are there any drawbacks of using SES v2?

[akefirad]

Hm good point. Since this is a major release, it wouldn't break existing code. The only thing I'm not sure is what you asked, is there anything we miss if we go with version2 altogether. I have to check. Would be nice if you have any connection with anyone on AWS side. (I'll try to dig into the docs anyway.)

[maciejwalkowiak]

@msailes are you aware of any drawbacks of switching to SES v2 or is it just a natural step and v1 should be considered as deprecated?

[akefirad]

As far as I can tell, they are not compatible, neither backward nor forward. Unless we hear something different from Mark, my guess is we have to support both. In the mean time, what do you think about having three interfaces and one implementation for each version:

public interface SendMessageResult {
  String getMessageId();
}

public interface AwsSesSimpleMessageSender {
  SendMessageResult send(SimpleMailMessage message);
}


public interface AwsSesMimeMessageSender extends AwsSesSimpleMessageSender {
  SendMessageResult send(MimeMessage message);
}

The scope of the above interfaces are just to convert the given message to an AWS SES request, send it, and return the result.
Then we can use the above interface bean in SimpleEmailServiceMailSender and SimpleEmailServiceJavaMailSender.

[maciejwalkowiak]

Lets rephrase it - what would make me use v1 for a new project? Is there anything in v1 that is not offered in v2?

[akefirad]

There's too much difference between the two at least in SDKs that it won't be easy to tell without knowing more about every single feature. I don't think it's safe to assume it's a simple upgrade. There seems to be functionalities that don't exist in SDK. Also different APIs means different permissions etc. So I'm not sure how migration-friendly the whole thing is. My suggestion would be to go with the abstracted interface. (I personally don't need V1, just thinking about the community.)