We are now able to send e-mails to our users and the email that we're sending out actually looks you
know reasonably good something that we can at least move forward with.
However there are still many rough edges to our application.
So we still have a lot of polish to do on our back end before we move over to the rock side and allow
users to create surveys over there.
So let's review our flow at this point.
We have created a new survey instance inside of our handler.
We then attempt to create and send an email through our mailer.
We do need to still in at times still add in some air checking code but after we do that we need to
make sure that we save the survey to our database and then eventually respond from the handler.
Now there's one other step inside of here as well that I forgot to mark on the diagram and that is to
make sure that we subtract 1 credit from our users after the survey is successfully sent out.
So remember we're charging users for this after we send the survey.
We're going to build the money.
So let's flip on over to our handler and make sure we take care of all these extra steps in there as
well.
I'm going to open up my code editor or find my routes survey routes file and then just for reference
I'm also going to open up my services mailer J.S. file as well.
Back inside Servais routes I'll scroll on down towards the bottom where we have our mailer sent.
So I think that the first thing that we need to do inside of here is make sure that after we successfully
send out this mailer right here we then take the survey that we created and we call save on it to save
it to our database.
Now one quick thing one quick thing to keep in mind when we called Meilleur does send right here.
This isn't a sync function.
And so we have to wait for the API request inside of it to conclude or for that mailer to be sent off
to send grid.
Before we go ahead and send the survey so mailer does send is in a sync function and we want to make
sure that we kind of pause and say Hey wait for this thing to finish what it's doing before going onto
the next line of code.
So we need to not only mark the mailer send function which is down here right here.
We need to not only mark this as being a sink but we also need to mark our route handler as being a
as well because it's also going to contain some asynchronous code.
So inside of our row handler will find the actual aero function that we passed in to abduct post.
Here it is way far over here and I'm going to make sure that I mark this thing as being async as well.
Now down at the very bottom of the handler we can successfully mark this thing as being a sync by saying
a weight right in front of it.
So before we start to do any saving or of any surveys or anything like that down here make sure that
the async code inside of Meilleur don't send is completed as well.
Now one quick thing one quick thing that we kind of neglected to do inside the send function we did
Mark send is being async and we've got the key word right here but we forgot to mark any individual
request in here with the a wait keyword.
Completely my mistake.
I completely forgot about it.
So this send off to the API right here at the request.
This is the actual API request right here.
So we're going to make sure that we put the a weight key word in front of that line like so.
OK so now when we call Meilleur don't send send will be executed and this overall request handler is
just paused not truly paused remember remember the way that there still promises behind the scenes here
stuff is still happening.
But we can kind of imagine that the overall handler is paused when this line of code hits the Meilleur
don't send function is then executed the request is created.
The request is sent out.
And then this send function pauses as well.
After we get a response back from the API control then flows back to the handler and we progressed past
this line right here so we can kind of stack up a sync awaits in async await statements like this to
make sure we have some kind of enhanced control flow as we start to call helper functions that are themselves
async away as well.
OK so after we take care of sending out the mailer after we have sent it out and we've now finished
the request off to the send grid API we can then immediately after save our survey.
So we're going to save our survey to a database by calling survey dog safe.
Again this is an asynchronous function as well and we want to wait for the entire thing to finish before
we attempt to do anything else inside the request handler.
So we will also mark this as being an asynchronous operation.
I'll say a weight survey that's safe and then after this we want to deduct 1 credit from our user and
then save our user as well.
So we'll say rec dot user dot credits Linus equals one we will then save our user as redcoat user save
We'll mark this as being async as well.
And then remember whenever we save the user on our request object we can now consider this user right
here to be Stael so to speak.
And so from this point on through our request handler we will use the user model that has returned from
the Save operation.
So whenever we do this save this will be eventually resolved with our user and this is going to be the
user that we use from now on.
So then at the very bottom we'll send back the updated user model.
We're going to send back the updated user model right here to specifically indicate like hey here is
the new value of credits just in the same way that we handled the credit EDITION earlier on.
Remember whenever a user pays us some money we send back the user model with the updated number of credits.
We do that so that the header inside of our application will automatically update.
So by sending back the user here as well we can make sure that we catch this updated user model inside
of our author reducer and get the header number of credits to update as well.
OK.
So this is looking good.
One last thing to do we need to make sure that we have some amount of error handling inside of here.
So there's a lot of places where things could go wrong.
We could accidentally send out a mailer that doesn't make it over Sangar it maybe says hey it looks
like something's wrong maybe something is wrong with the survey maybe something's wrong with the user.
So there's a lot of places where something can go that try catch syntax that we always use with the
async await key words to watch these three await keywords and say hey if anything goes wrong with these
three async statements just catch the request and immediately send back a response.
So I'm going to wrap all this stuff inside of a try block like so if anything goes wrong we will catch
the air and then we will immediately send a response back to the user.
Now in this case the status that we'll use here is a little bit ambiguous.
There's a lot of different things that can go wrong but we are in general are just going to assume that
the user might have sent us a poorly formed survey or something like that.
So we will say status 4:22 which means an process on process Sipple entity which in other words means
something is wrong with the data you sent us.
So we're going to tell the user hey you did something wrong and we will just send back the entire error
message like so.
OK.
So this is looking pretty good.
I think that we're ready for one more test out.
So once we test this stuff will then be able to verify and say OK did we create a survey inside of our
database.
Did the number of credits get deducted all that kind of stuff.
So let's check our terminal make sure nothing's going wrong over here.
Looks good.
I'll flip back over to my re-act application.
I don't need to refresh the reac side.
I can just immediately make another post request over to X-ers with the same survey that we were using
previously.
So I'm going to clear up my request log will send the survey and I get back a status 200 that contains
the updated user inside of here.
You'll see that we now have nine credits because we just used one credit to update or to send out that
new survey.
If I go over to my Gmail account you'll see that I've now got a new e-mail over here.
So here's the second survey that we just followed up with.
And then we can also go back over to our lab database.
You might not have any lab open anymore.
Soooo if you want to pause the video pull up in lab but you can just look at mine and you know hey confirm
or get a good idea of what happened.
So if I now refreshed my database we should see that first survey appear inside of our surveys collection.
So here's our brand new surveys collection.
If I look into it I will see my survey right here.
So I should be able to kind of zoom in on this.
Here we go.
So I've got the title to survey the subject the body.
Here's the link to the user who owns it.
Here's the date that it was sent.
The number of clicks on it.
And then here is my sub document collection every sub document inside of the recipient list has the
email property.
So here's the e-mail of the recipient.
Here's the idea of this very particular sub document and the responded property as well.
Awesome.
So looks like we are on a great track here.
It looks like everything is starting to come together.
Let's continue in the next section where we're going to kind of go back to the grid API and figure out
a little bit more on the klick tracking side of things specifically.
I just want to make sure that said grid is aware of who is clicking on these emails whenever someone
clicks on yes or no inside them.
So let's take a quick break and continue in the next section.