WEBVTT

NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com

00:00:01.096 --> 00:00:04.626 align:middle
When we send this email, it's
sent right away - synchronously.

00:00:05.166 --> 00:00:07.746 align:middle
This means that our the user
sees a delay while we connect

00:00:07.746 --> 00:00:09.906 align:middle
to the mailer transport to send the email.

00:00:10.426 --> 00:00:14.806 align:middle
And if there's a network issue where the
email fails, the user will see a 500 error:

00:00:15.086 --> 00:00:19.076 align:middle
not exactly inspiring confidence in a company
that's going to strap you to a rocket.

00:00:19.656 --> 00:00:22.666 align:middle
Instead, let's send our emails asynchronously.

00:00:23.076 --> 00:00:28.236 align:middle
This means that, during the request, the email
will be sent to a queue to be processed later.

00:00:28.706 --> 00:00:30.896 align:middle
Symfony Messenger is perfect for this!

00:00:31.136 --> 00:00:34.926 align:middle
And we get the following benefits:
faster responses for the user,

00:00:35.266 --> 00:00:39.576 align:middle
automatic retries if the email
fails, and the ability to flag emails

00:00:39.576 --> 00:00:42.166 align:middle
for manual review if they fail too many times.

00:00:42.796 --> 00:00:43.876 align:middle
Let's install messenger!

00:00:44.176 --> 00:00:50.386 align:middle
At your terminal, run: composer require
messenger Like Mailer, Messenger has the concept

00:00:50.386 --> 00:00:53.836 align:middle
of a transport: this is where the
messages are sent to be queued.

00:00:54.376 --> 00:00:57.206 align:middle
We'll use the Doctrine transport
as it's easiest to set up.

00:00:57.786 --> 00:01:04.836 align:middle
composer require symfony/doctrine-messenger
Back in our IDE,

00:01:05.216 --> 00:01:12.136 align:middle
the recipe added this MESSENGER_TRANSPORT_DSN to
our .env and it defaulted to Doctrine - perfect!

00:01:12.636 --> 00:01:14.986 align:middle
This transport adds a table to our database

00:01:14.986 --> 00:01:17.586 align:middle
so technically we should
create a migration for this.

00:01:18.016 --> 00:01:21.466 align:middle
But... we're going to cheat a bit and
have it automatically create the table

00:01:21.466 --> 00:01:22.456 align:middle
if it doesn't exist.

00:01:22.866 --> 00:01:25.566 align:middle
To allow this, set auto_setup to 1:

00:01:26.166 --> 00:01:30.466 align:middle
The recipe also created this
config/packages/messenger.yaml file.

00:01:31.126 --> 00:01:32.996 align:middle
Uncomment the failure_transport line:

00:01:33.556 --> 00:01:36.336 align:middle
This enables the manual failure
review system I mentioned earlier.

00:01:36.956 --> 00:01:42.066 align:middle
Then, uncomment the async line under transports:
This enables the transport configured

00:01:42.066 --> 00:01:45.936 align:middle
with MESSENGER_TRANSPORT_DSN and names it async.

00:01:46.526 --> 00:01:50.366 align:middle
It's not obvious here, but failed
messages are retried 3 times,

00:01:50.416 --> 00:01:52.556 align:middle
with an increasing delay between each attempt.

00:01:53.196 --> 00:01:58.496 align:middle
If a message still fails after 3 attempts, it's
sent to the failure_transport, called failed,

00:01:58.806 --> 00:02:03.056 align:middle
so uncomment this transport too: The
routing section is where we tell Symfony

00:02:03.056 --> 00:02:05.476 align:middle
which messages should be
sent to which transport.

00:02:05.986 --> 00:02:09.186 align:middle
Mailer uses a specific message
class for sending emails.

00:02:09.396 --> 00:02:15.186 align:middle
So send Symfony\Component\Mailer\Messenger
SendEmailMessage

00:02:15.476 --> 00:02:18.106 align:middle
to the async transport: That's it!

00:02:18.326 --> 00:02:21.076 align:middle
Symfony Messenger and Mailer
dock together beautifully

00:02:21.076 --> 00:02:23.156 align:middle
so there's nothing we need
to change in our code.

00:02:23.156 --> 00:02:24.796 align:middle
Let's test this!

00:02:25.156 --> 00:02:25.906 align:middle
Back in our app...

00:02:26.016 --> 00:02:26.636 align:middle
book a trip.

00:02:27.136 --> 00:02:31.036 align:middle
We're back to using Mailtrap's testing
transport so we can use any email.

00:02:31.736 --> 00:02:34.016 align:middle
Now watch how much faster this processes.

00:02:34.436 --> 00:02:39.056 align:middle
Boom! Open the profiler for the last
request and check out the "Emails" section.

00:02:39.936 --> 00:02:43.036 align:middle
This looks normal, but notice
the Status is "Queued".

00:02:43.526 --> 00:02:47.046 align:middle
It was sent to our messenger
transport, not our mailer transport.

00:02:47.736 --> 00:02:49.466 align:middle
We have this new "Messages" section.

00:02:49.926 --> 00:02:55.006 align:middle
Here, we can see the SendEmailMessage
that contains our TemplatedEmail object.

00:02:55.566 --> 00:02:57.286 align:middle
Jump over to Mailtrap and refresh...

00:02:58.426 --> 00:02:59.056 align:middle
nothing yet.

00:02:59.516 --> 00:03:00.166 align:middle
Of course!

00:03:00.226 --> 00:03:01.526 align:middle
We need to process our queue.

00:03:01.956 --> 00:03:03.596 align:middle
Spin back to your terminal and run:

00:03:03.756 --> 00:03:13.576 align:middle
symfony console messenger:consume async -vv This
processes our async transport (the -vv just adds

00:03:13.576 --> 00:03:15.536 align:middle
more output so we can see what's happening).

00:03:16.096 --> 00:03:16.816 align:middle
Righteous!

00:03:17.026 --> 00:03:19.266 align:middle
The message was received
and handled successfully.

00:03:19.666 --> 00:03:22.136 align:middle
Meaning: this should have
actually sent the email.

00:03:22.676 --> 00:03:23.636 align:middle
Go check Mailtrap...

00:03:24.246 --> 00:03:25.036 align:middle
it's already here!

00:03:26.096 --> 00:03:26.796 align:middle
Looks correct...

00:03:26.796 --> 00:03:28.536 align:middle
but... click one of our links.

00:03:29.396 --> 00:03:29.946 align:middle
What the heck?

00:03:30.406 --> 00:03:33.036 align:middle
Check out the URL: that's the wrong domain!

00:03:33.446 --> 00:03:38.936 align:middle
Boo. Let's find out which part of our email
rocket ship has caused this and fix it next!