Skip to content

[Mailer] Use AsyncAws to handle SES requests #35992

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 3, 2020
Merged

Conversation

jderusse
Copy link
Member

@jderusse jderusse commented Mar 6, 2020

Q A
Branch? master
Bug fix? no
New feature? yes
Deprecations? no
Tickets #33183, #35468 and #35037
License MIT
Doc PR TODO

alternative to #33326

This PR replace the native code to call AWS SES by the new AsyncAws project maintained by @Nyholm and me.

This removes complexity of signing request, and adds new features likes:

  • authentication via .aws/config.ini, Instance profile, WebIdentity (K8S service account)
  • usesignature V4 (the one recommanded by the Official SDK )
  • fully compatible with API (uses the official AWS SDK interface contract to generate classes)

Because it's based on symfony/http-client, it's fully integrable with Symfony application.

new SesApiTransport('ACCESS_KEY', 'SECRET_KEY'),
'ses+api://ACCESS_KEY@email.eu-west-1.amazonaws.com',
new SesApiTransport(new SesClient(Configuration::create(['accessKeyId' => 'ACCESS_KEY', 'accessKeySecret' => 'SECRET_KEY']))),
'ses+api://ACCESS_KEY@us-east-1',
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it a BC Break?

if ($email->getAttachments()) {
return [
'Action' => 'SendRawEmail',
'RawMessage.Data' => base64_encode($email->toString()),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is probably the issue of #35037

$simpleMessage->setBody(new Body([
'Text' => [
'Data' => $email->getTextBody(),
'Charset' => $email->getTextCharset(),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this were not provided in current version

@chalasr chalasr changed the title Use AsyncAws to handle SES requests [Mailer] Use AsyncAws to handle SES requests Mar 7, 2020
@chalasr chalasr added the Mailer label Mar 7, 2020
@chalasr chalasr added this to the next milestone Mar 7, 2020
@chalasr
Copy link
Member

chalasr commented Mar 7, 2020

IMHO AsyncAWS should also be a soft dependency when using the HTTP transport.
I think we would better preserve the current implementation and wire the AsyncAWS one when it is installed, since it is not a core dependency.
Installing it by default could then be handled in a flex recipe.

@Nyholm
Copy link
Member

Nyholm commented Mar 12, 2020

Thank you for the PR and thank you @chalasr for the review. I agree with you. AsyncAws should be a soft dependency. Currently it is only installed in require-dev section. If you are trying to use features that require the external library you get an exception. See https://github.com/symfony/symfony/pull/35992/files#diff-4e7b1bdc9093065fae5fff42cdde5d8cR42

@chalasr
Copy link
Member

chalasr commented Mar 13, 2020

@Nyholm My point is: we have an HTTP implementation that works out of the box currently. Requiring AsyncAWS to be available for using the HTTP transport implicitly makes it an hard dependency, even if it's not in the require section, since you now get an exception instead of something that works immediately.

Considering the pros + the fact that AsyncAWS is maintained by two core members, I'm OK for requiring it with a meaningful exception.
But still, throwing in 5.1 is a BC break. IMHO we should deprecate the current implementation first, suggesting to install the missing package as it will be required in 6.0, and automatically wire the AsyncAWS-based implementation when it is installed.

@Nyholm
Copy link
Member

Nyholm commented Mar 14, 2020

Thank you. I understand the point you are trying to make.

we have an HTTP implementation that works out of the box currently.

Yes, But it has some bugs and it does not support all authentication mechanism available for AWS.
Of course, bugs can be fixed and authentication can be implemented.
We created AsyncAws to be able to abstract authentication away from this bridge. (And possible other parts of the symfony organization that may use AWS). We are also happy to extend the maintainer team with more Symfony core members if there is a wish for that.

But still, throwing in 5.1 is a BC break.

True, but this component and this bridge is still marked as experimental.


Side note: Most code in Async AWS is generated so the maintenance is kept to a minimum.

@Nyholm
Copy link
Member

Nyholm commented Mar 14, 2020

True, but this component and this bridge is still marked as experimental.

Oh no.. @chalasr pinged my privately and very politely pointed out that I was wrong. This component is not experimental.

@jderusse
Copy link
Member Author

Thanks you for your review @chalasr. I agreed with you, The current HttpClient implementation should stay for BC.

But as @Nyholm pointed it, this implementation have several opened bugs. One of them is the way the request is signed. It currently use the version 2 which is not supported by all regions (https://docs.aws.amazon.com/general/latest/gr/signature-version-2.html). And maintaing a new implementation, is not trivial (see async-aws or AWS SDK)

I suggest to use the AsyncAws Adapter when installed package is installed otherwise to fallback to HttpClient Adapter (as suggested by @chalasr), AND to deprecate the HttpClient Adapter in 5.1 to remove the complexity from Symfony.

WDYT?

@nicolas-grekas
Copy link
Member

Since this is experimental, we can break BC and cut maintenance efforts.

@chalasr
Copy link
Member

chalasr commented Mar 15, 2020

@nicolas-grekas Actually, this is not experimental :) #35992 (comment)
@jderusse Sounds like a plan!

@jderusse jderusse force-pushed the ses branch 2 times, most recently from 06828b9 to 0da08e2 Compare March 15, 2020 22:44
@jderusse
Copy link
Member Author

PR updated according our discussion.

@chalasr
Copy link
Member

chalasr commented Mar 17, 2020

Tests seem broken

@jderusse jderusse force-pushed the ses branch 3 times, most recently from e298f62 to 55fa287 Compare March 18, 2020 22:48
@chalasr
Copy link
Member

chalasr commented Apr 12, 2020

Rebase needed

@connorhu
Copy link
Contributor

@jderusse Since this is an alternative solution, can I close the #33326 pull request?

@Nyholm
Copy link
Member

Nyholm commented Apr 24, 2020

@connorhu Probably, but let's wait to see if this PR is accepted. If this PR is rejected then #33326 might be something that should be considered.

Copy link
Member

@Nyholm Nyholm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is ready for merge we should release 1.0.0 of async-aws/ses.

@jderusse Could you verify the failing tests?

Copy link
Member

@chalasr chalasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI failures are unrelated. 👍

@fabpot
Copy link
Member

fabpot commented May 3, 2020

Thank you @jderusse.

@fabpot fabpot merged commit 669b7f1 into symfony:master May 3, 2020
@jderusse jderusse deleted the ses branch May 3, 2020 15:31
fabpot added a commit that referenced this pull request May 3, 2020
…ication (jderusse)

This PR was squashed before being merged into the 5.1-dev branch.

Discussion
----------

[AmazonSqsMessenger] Use AsyncAws to handle SQS communication

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | /
| License       | MIT
| Doc PR        | /

Similar to #35992 this PR use AsyncAws to handle Sqs messages sent/receive

It move complexity of authentication/streaming outside Symfony while keeping HttpClient integration.

Commits
-------

7c4888e [AmazonSqsMessenger] Use AsyncAws to handle SQS communication
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.1 May 4, 2020
@fabpot fabpot mentioned this pull request May 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants