The last video we spoke about how we were going to take our instance of a survey and an e-mail template
that we're about to create and merge the two together inside of a Meyler object at the very end I had
said that somehow communicating this mailer off to the email provider is a rather complicated process
particularly for the application that you and I are going to build.
So let's dive into this.
We're going to figure out why it's challenging and why this is all such a big deal.
OK.
So again we're going to look at a diagram here.
That's going to help you understand exactly how this mailer gets sent off to the e-mail provider.
We're going to look at two different diagrams.
The first diagram is going to show you a bad way of communicating the mailer to the provider.
And the second one is going to be the good way the way in which we are going to do it.
So let's take a look.
OK.
So this is the bad approach here.
This is what you and I do not want to do in this type of approach.
I'm saying that for every single recipient inside of our survey list we could create a separate mailer
object.
We could then send that mailer object off to our e-mail provider and that e-mail provider would that
send the e-mail off to the individual recipient.
Now why might this be about approach right here.
Well when you think about it if we say that for every single recipient we are going to create one mailer
object.
And then in one single HTP request we're going to send each and every Mailer or excuse me one separate
request for every mailer.
We would then have ten thousand or a thousand or 100000 separate requests required to handle one survey.
In other words for every single recipient who is inside of one survey be it 1000 10000 or 100000.
We will.
We are saying that we're going to create a separate Mailer and communicate it to our e-mail provider
in a separate HTP request.
Now obviously off the bat we probably don't want to make a separate request over to this e-mail provider
for every single recipient.
It would be a lot better if we could somehow take all of these recipients create one mailer object and
then just take that one single e-mail or that one single Mailer and communicate off to our e-mail provider.
In other words I want to do a sort of batch operation and say for all the different recipients who are
attached to a single survey just make one mailer and send it off.
And so that's exactly what we're going to do.
We're going to take all of the different recipients who are included inside of our survey.
We're going to create one single mailer object and then we're going to pass that mailer off to our e-mail
provider and one Cingular network request will then leave it to our e-mail provider to figure out exactly
how to handle the e-mail to each individual recipient.
OK.
So this is the approach we're going to take right here for all these different recipients.
Will make one mailer we'll send the one mailer off to the e-mail provider.
Now how does this approach affect our application and it really does in a big way.
So let's kind of break this down let's consider some of the cons of this approach right here and figure
out exactly how we're going to address them inside of our application.
First thing I want to do is look back at a diagram that we were just glancing at in the last video.
Remember we had said that for a given mailer we have one survey instance and we have one e-mail templates
and this e-mail template right here provides the kind of HVM L or kind of the body of the actual e-mail
that a user receives.
So essentially that e-mail template is creating this stuff right here.
The message to the user.
And it also is going to set up the two possible links that a user can click to provide feedback to our
application.
So if we are using the exact same templates the exact same Like instance of the template for all these
people what's the downside to that.
Let's think it through for a minute.
So if everyone is getting the exact same e-mail like I mean every last character 100 percent identical
even the links inside the e-mail are identical.
And that's the important part here.
So let's imagine that everyone is getting the exact same links and the e-mail.
How are we going to somehow understand who clicked on a link.
Whenever they do.
Like if you get this e-mail and you click on No right now how am I going to know that you clicked on
this e-mail as opposed to someone else.
And why do we care about that at all.
Well remember that was the entire purpose of recording that list of recipients inside of our survey
schema we had said that we want to store the list of recipients so that for every different email we
send out or every single recipient we have indicated by this e-mail property right here we want to make
sure that we record whether or not they have responded to the e-mail previously.
And that we were going to do that to make sure that we kind of put a curb on any sort of duplicate votes
inside of our application.
We don't want people to be able to vote multiple times.
So we were going to start off everyone with a responded Of false.
And then after you provide us feedback one time we flip this over to true.
And then after that we no longer record your votes.
So remember we went through this entire process of ensuring that we could somehow uniquely identify
people in order to combat possible fraudulent votes or duplicate votes.
And so when you look back at the actual e-mail right here it obviously becomes very pinnacle to make
sure that you and I understand exactly who is clicking on this link.
Now why is this such a challenge.
Remember again you and I we do not or we are not going to have the ability to create a separate link
right here for every individual user because everyone is going to be getting the same exact mailer so
everyone sees the exact same link so just to kind of drill this point home because I want to make sure
that it's really clear really you know very very clear.
The last thing I want to say here is in a perfect world we would have been able to set up this route
right here or this link right here as send you to somewhere like email dot com surveys slash feedback.
And then maybe we indicate the idea of the survey with like you know 1 2 3 right here.
So maybe this email corresponds to survey 1 2 3.
And then maybe if the user clicked on the no button we would do something like Slash no to say save
the user clicked on no.
And then in the link right here Ideally we would have been able to put the user's e-mail address so
something like email or user out example dot com.
So inside of just the URL of this link right here or if someone clicked on this link we could say OK
someone's trying to give us feedback for survey 1 2 3.
They want to vote no.
And here is the e-mail address of this particular user.
So if we've been able to do something like this it would have solved all of our problems and we could
say that we could customize every single link here when the user clicks it just by the path that the
user linked on we can figure out exactly what to do.
And so what I'm saying very clearly here I'm trying to make sure this is really clear.
I'm telling you that everyone is going to get the exact same link so we cannot somehow communicate the
email inside the link.
This is the best we can do right here.
At best we can say hey if you click on this link it'll take you to feedback for survey 1 2 3 and you
are attempting to vote yes or no.
We cannot put any identifying token into the email because everyone gets the exact same one from a single
mailer.
OK.
So I feel like it probably drilled at home enough.
Hopefully you understand it by now hopefully understand that we need some mechanism to uniquely identify
users who click on these links.
So obviously there's a solution to this.
Let's talk about what we're going to do.
So to solve this problem this is going to go into a little bit of the behind the scenes stuff with our
e-mail provider and the e-mail provider that we're going to use.
So I can tell you right now is a provider called cent..
So we'll sign up for this provider in just a minute.
But if you want to you can open up a new browser tab and go to send grid dot com and check out a little
bit there documentation.
So we're going to talk a little bit about what send grids does behind the scenes.
That's going to solve this problem that we have been able to identify our users uniquely.
All right.
So let's get to it.
So whenever we send grid to send out an e-mail to one of our users send grid does something a little
bit automatic behind the scenes for us.
Here's what they do for each user that centigrade is going to send an e-mail to they look at the body
of the e-mail and they look to see if any links exist in that e-mail.
And in our case there will be links right where we have the yes link and then no link.
We never send grid sees a link inside of our e-mail.
They automatically replace the link with a customized link that sends the user to their own servers.
So in other words regardless of what you are l you and I put inside these two links right here regardless
of what you and I do when censored sends out this e-mail they are going to replace the destination links
inside of here with links that send the user to their own personal send grid server.
And they do this to build a collect metrics on what links people are clicking inside of all these different
e-mails they're sending out.
So whenever a user clicks on Aslund great here they will be sent off to send grid's server grade is
going to record some analytic information about the user and then send good sense off the user to the
actual destination of the link like the actual original destination.
So how is that going to help us out here.
Well here's what happens.
So when we tell grid to send an e-mail out to people send it is going to scan the e-mail.
It's going to replace every link with their own very individual special one.
And then here is the very important part here.
When when when grid replaces these links with their own special ones they customize the links for each
individual person that the e-mail is going to be sent out to.
So even though you and I are communicating this email over to send grade with a single mailer object
which room which means that we only have like exactly one unique copy the e-mail sent grid goes back
through the e-mail in that customizes each e-mail to be very particular to every specific recipient
every specific person who actually gets the e-mail.
So when Segretti replaces these links they put some token into the link that uniquely identifies the
user.
So send Gred in fact knows what user is clicking on a link.
We don't send grid does because they go through this customization process just for the purpose of collecting
some type of metrics.
So what we really want to do is somehow get censored to tell us whenever someone clicks a link on an
e-mail.
And that's exactly what we're going to do.
So after sending semi-rigid replaces all these links they send out the e-mail a user clicks on the link
send grid sees that the user clicked on the link.
They know exactly who clicked on it.
The user gets sent off to the destination and the user is happy.
But then more importantly Saenger then sends a little message to our server informing us that hey someone
just clicked on one of your links.
Here's the link it was.
And here is some information about that particular user who clicked on the link specifically the e-mail
address of the person who clicked on it.
And so this whole process right here is what is going to save us from not knowing who clicks on the
link.
So one more time.
I know it's a long section.
I know that I'm repeating this stuff about why the links you know why we can't really use this effectively.
But I again I really want to make sure that this stuff is very clear because we are definitely in a
jump through a couple of hoops to make sure that all this stuff works correctly and I want to understand
why we're taking this extra trouble.
So from the top.
One more time you and I are creating a single mailer object that mailer contains exactly identical content
for every single user that we are sending the survey out to.
So we have no ability to customize these links on a per user basis.
So we do not know who is clicking on any individual link.
Thankfully when we tell it to send out the e-mail send great is going to replace every link with one
of their own and the link that says great replaces it with is a very special link that is customized
for each individual particular recipient of the email after the user clicks on the link send grid then
knows exactly who clicked on it because they customized the link for every individual person said Great
Well then send a message to our server telling us about the link now this very last step of the process
here where second grade eventually sends a message back to our server telling us that someone clicked
on something just you know this process is referred to as a web hook a web poke is anything where some
outside API is kind of facilitating some process and then gives our application some type of callback
or some type of little notice that some events just occurred.
So we refer to this as a web book.
And so maybe now if we go back to our route definitions Baqir the route we had spoken about to record
feedback from a user we had named it API slash survey slash web hooks.
So this right here this route is going to be a route that only send grid accesses and send it at some
intervals are going to be sending us a little notification saying hey someone just clicked on one of
your links.
Here's the information about it.
So that's why we call this thing Web hook back here.
OK.
So that's the entire process.
It is the I think that we've gone through it in great deal detail at this point.
So let's take a quick break.
We're going to come back in the next section.
We're going to start to sign up with send grid and integrate center grid into our application in order
to send out all these e-mails.
So see in the next section.