In the last section we changed up our e-mail template to make sure that whenever a user clicks on a
given survey we get communication through our cell grid web look of exactly what survey the user was
responding to and whether or not they clicked on the yes or the no buttons.
Now we are receiving an array of these events from our censored web hook.
So we need to now think about how we're going to iterate through this list of events find the correct
surveys and then add to their yes or no property to say hey here's some additional amount of feedback.
Now before we start to iterate through this list of all these different events here I want to tell you
about some different weaknesses that we might have inside of our code base right now or maybe a better
way to put it would be some possible pitfalls we could run into as we start to process this list of
events right here.
So the first thing I want to do just to prove a point to you just to give you a demonstration of a possible
pitfall or possible gotcha that we might run into I'm going to go back over to my email account right
here.
So here's the survey that I just clicked on and in very quick succession.
I'm going to click on yes two times in a row.
So I just clicked on yes two times in a row.
Now we're going to flip back over to the terminal and wait for that web hook to pop up on the screen
just a little bit.
When we get the Web hook to actually console log over here again you're going to notice that the web
contains two separate events one event.
First the first click and then the separte that for the second click.
Now remember it's really important inside of our application to make sure that we only ever allow a
user to vote one time on any given survey to make sure that that really happened to make sure that was
100 percent the case.
We had put together that sub document collection of recipients.
Remember we said that every recipient had an e-mail property and a voted property or something like
that to track whether or not a user had voted or in particular someone with that particular e-mail had
voted on a particular survey.
So we do have that kind of prevention layer inside of our application right now.
We've got something to say hey make sure people can't do duplicate votes how ever even with that system
in mind.
And here's my console logs those two clicks I just did.
You'll notice that I've gotten identical e-mail in both them and in identical you are out.
So even though we've got that type of system in place to kind of make sure that the user is not allowed
to vote multiple times I'm still kind of afraid that as we start to process this list of events right
here we might get ourselves into some case where we accidentally say maybe increment the number of yes
responses that we have on a survey and then save that to let you know and then mark that recipients
haven't answered.
And then simultaneously like at the exact same time we might accidentally also process the second event
right here and also start to and comment that yes vote on the survey and also Mark that recipient as
having answered in other words you never know you might get into some type of race condition where you
start to accidentally modify one record.
As we were modifying or as we're about to reach and modify it a second time.
Basically all I mean to say is that before we start to process this list of events I think that we should
do a little preprocessing step on it and make sure that we somehow remove any duplicate results.
In other words any duplicate clicks where a record or two events inside of here have identical e-mail
and identical you or else.
So this is something that is not necessarily you know super necessary inside of an application like
we're talking about a real edge case right here.
But I just mean to suggest that just to code very defensively here just to assume that maybe this web
poll is going to be acting funny sometimes Let's do some filtering ahead of time and make sure that
we do remove any duplicate clicks out of this.
Now there's one other thing I want to mention here about this pre-processing step that we might want
to do.
You'll remember that when we put together the web configuration on the second grid Council we had specifically
said only notify us about click events.
So like whenever a user clicks on an event only notify us about those.
So we can very easily or at least I can I can very easily imagine a situation where maybe some other
developer goes into our Send grid console and accidentally starts tweaking around some stuff on the
web poke stuff and maybe they say Oh Wolf for this other feature I'm working on.
I also want to know about whenever an e-mail bounces or something like that.
And so I personally can very easily imagine a case in which we start to get event objects inside of
this callback that are not of type event click.
So in addition for this preprocessing step I think that we should also make sure that we only feel or
that we filter out to some degree only events that are of type click.
Because even though we are only asking grade for click events right now I can again I can really imagine
a case in which some other developer accidentally starts messing around with our Send grid settings
and we start getting event objects in here with a type other than click.
So that's another thing that I think we should be really aware of.
And the last thing I want to be aware of even if it a event object in here has type click I can again
really imagine a case where we might start putting two other links inside of our e-mails so maybe we
also provide a user a link to like some terms of service or to our Web page of email dot com or something
like that.
And so even if a event object inside of it is of type click I can also imagine a case where we start
getting you or else that don't strictly follow this API slash surveys survey ID slash Yes type of schema
maybe at some point if we also put in a link to our home page we might see events with type of click
that have a U or l of w w w dot e mail dot com or something like that.
So that's a couple of different situations in which I can very easily imagine that this list of events
that we get back from Send grid's starts to have some data that doesn't strictly conform to what we
are expecting it to.
And so again I think that we really need to do some amount of pre-processing to make sure that we don't
accidentally say whoa here's this crazy object of type like bounce and it doesn't have a u r l or maybe
it's the event object of type click and it does have a U or L but it doesn't have a survey ID inside
of it.
So again I think that we need to write our logic for our request handler for handling this website.
Well put stuff in a very defensive fashion and kind of just assume that we might be getting a lot of
junk data inside of there.
So with all that in mind I want to take a break right now.
When we come back in the next section now that we understand why we might want to do some type of pre-processing
or filtering step.
Honestly that list I want to come back in the next section and talk about exactly how we're going to
do this sort of processing pipeline.
Before we start to actually mess with any surveys that are in our database.
So let's take a quick break.
We'll come back in the next section and talk about how we are going to put this pipeline together.