In the last section we got to have a good discussion about how to react to server and the expressed
server are working together and the differences between them in the development world and the production
world we're not going to continue in this section with what is going to be a another pretty long video.
So going to prothesis right now in a sense is a long video.
But this is an optional video.
So this is the one where we are going to go into a lot of kind of crazy stuff where we talk about a
lot of the intricacies of our server.
I want to make sure that it's really clear to you this is completely optional.
So if you don't want to hear about any of this search server setup or proxy stuff for blah blah blah
how all this stuff is working.
That's totally fine.
You don't really need to know this stuff to be able to build applications.
But of course I'm going to tell you this is how you get to be a really good engineer.
So of course I recommend you watch this but I want to tell you you don't have to.
So if you don't want to hear any of that positivity right now go on to the next one.
Totally fine.
OK.
So if you're still here and I know you're all here I know you are.
Let's let's get to it.
So we're going to talk about a couple different issues.
Again this will be a long video.
I apologize ahead of time but I want to do it.
Everything is just in one single video so we just kind of get it all out of the way and talk about all
these really important concepts that are kind of going on behind the scenes.
So I want to reiterate the fact that as we have spoken about the server so far everything like works
well it's very elegant.
It works very well in development and works equally well in production.
Everything feels fantastic.
But as soon as we start talking about some of the inner workings you very likely will say to me Stephen
why are we doing things this way it seems crazy.
So I can't say it enough at surface level it works together very well and it's a completely reasonable
server setup that we have right here.
But once you start to understand the inner workings you really get the feeling that wow there really
are a lot of moving parts here and there's just a lot of stuff that's happening.
OK.
So let's dive into it.
The first thing I want to do if you recall in the last section we had updated that redirect you or I
and I had said that it takes some time for this thing to actually percolate through.
We didn't actually get back to testing it.
And the last video that was my mistake.
So just really quickly if you go back over to localhost 3000 and click on sign in with Google the redirects
you or I should now be white listed and you'll see something like this.
You can authorize it and you will eventually end back at that same kind of error message that we've
seen all along.
So again this message right here is really fine.
We'll come back very shortly and fix it all up.
So looks like yes the stuff is working correctly.
So I want to now start talking a little bit about our general server setup and why we made some of the
decisions that we did not why we made the decision.
I want to make like some of the considerations clear.
OK.
So the first thing you might be sitting here wondering is Stephen why do we have like you whatever Stephen
I can get by the like two separate servers like this.
You know whatever I can deal with it.
But you know I understand why they condensed down into one server like this.
But why didn't we take some type of other more reasonable approach something like where we have something
that looks like this where we have one create react up server that serves up the bundled J.S. file.
Then we have a completely separate API and we just say you know what looks stomack it we're just going
to deal with handling these different domains.
We'll figure out some elegant solution whatever we'll figure out.
I don't care about having to specify the domain between production development.
We can figure that stuff out.
And besides that maybe we even want to have a approach like this because maybe we are trying to work
with some other existing API that doesn't really have the ability to take a reactivates app on top of
it.
You know maybe you are working at a large enterprise company where you have teams and teams of engineers
working on really heavy back ends that are solely intended to be used as API servers.
And so we don't want to deal with any of this like round condensing stuff or anything that we want to
have this distinctly separate very different API on a different domain that we can always access no
matter what.
So I say okay okay that's totally fine.
I have even advocated around approach approaches like this in other courses of mine.
I've very clearly said in other courses Yes we're going to have one server that serves up all the development
assets and then another that acts as the API that serves up all the information for our app.
So this is a completely fine approach.
Don't get me wrong.
We certainly have could have taken our application in this direction we could have certainly put together
some type of architecture like this.
But there's a couple of reasons that we were prevented from doing this easily inside of our application.
OK.
Now I can use the word like prevented very carefully.
I'm going to say that we could have worked around these issues with some challenges we could have gone
in this direction but we decided to keep things easier and straightforward and kept them the way they
are.
So I'm going to lay out those two issues you lay out the two are the two kind of reasons that made our
life easier by taking this sort of approach right here.
OK.
So the first reason I want to remind you that we are using cookies as the absolute linchpin for authentication
in our application.
We have said repeatedly once the user goes through the overflow we're going to set up some type of information
in the user's cookie that's going to identify the user and then EBS every subsequent request.
Back to our server will contain that user's ID.
And that's that's it that's the whole shebang that's how we're doing authentication right.
And we've spoken at such great length about this.
So here is issue number one.
And here's the reason why we took our particular architecture let's imagine that we have some browser
that is currently pointed at localhost three thousand if our browser at localhost 3000 makes some type
of Ajax request like let's say we're trying to access our API fetch a list of surveys or whatever it
is we're trying to do inside of our app when we make that request to a server at a local host 3000 which
is the exact same domain that the browser is currently at.
Cookies will be included with the request.
However if we make a request to local host.
5000.
So in other words to some different domain that houses our API server browser cookies are not included
with that request by default because our browser is currently pointed at localhost 3000.
Now this is purely a security issue purely security.
We are.
The browser assumes that if you're at localhost 3000 and you make a request to local host 3000 hey you
know what.
No problem whatsoever include the cookies.
Everything is fine.
Make it happen.
Who cares.
But if your local has three thousand and you make a request to close to 5000 wall sudden the browser
starts getting really suspicious the browser starts thinking why is this web page trying to make a request
to localhost 5000 Why are they trying to make a request to a different domain to a different server
to a different port specifically a different port.
Here the browser assumes that it might have loaded up some malicious javascript code that is attempting
to make a request maliciously to some different domain.
And so by default the browser will not include cookies with that request.
Solely a security issue and it's completely triggered by the fact that the browser is currently visiting
one domain.
And we are trying to make a request to a different one.
And yes a different port counts as a different domain.
So it can be this could just as easily been like we were at Google dot com and trying to make some some
Ajax requests to like urban B.Com.
So if our browser was pointed at Google dot com and we made an Ajax request over to Air B and B cookies
would not be included that request by default because it's a different domain.
Again purely a security concern.
So again by using localhost three 3000 by keeping this or byte excuse me we back effort.
Can we just say by taking this sort of architecture where we say we are always make your request to
localhost three thousand and then we rely on create re-act up to 4 that request onto the API.
We completely skirt this entire issue as far as the browser is concerned.
Any API requests we make at all from the browser will always be pointed back at Create re-act out in
development and then create re-act that will automatically proxy that request onto the Express API.
The browser does not know that that proxy is there at the browser doesn't know it couldn't care.
So the broad browser makes the request to the proxy.
It's thinking oh hey I'm a local host 3000 and I'm making a request to the server at local House post
3000 sure same domain.
I'm going to include the cookies.
Everything is A-OK.
Then the proxy takes that request.
It takes a copy of the cookies and forwards it onto the Express API.
And so as far as you and I can are concerned on the Express API Hey we got our cookies.
We know who this user is.
We're going to formulate a response and send it back and it's eventually going to and backup out the
server.
And then of course as we've discussed inside production that express or Scuse me that create re-act
out sort of falls away.
And so in production mode the browser will always be at Heroku outcome or whatever we're going to make
a request to our express API on the same exact domain.
And so none of this cross-domain cookie stuff is an issue at all.
OK so that's reason number one.
So in this case you know what the browser does have API to allow us to send cookies across domain.
It's there we could take this approach we could do it.
We can make it happen.
But again I'm just saying life is easier when we don't have to worry about these advanced issues right.
We just don't have to worry about it now.
We can use cookies all the authentication stuff is pretty straightforward relatively at least as far
as the browser is concerned.
And life is easy don't have to worry about Jason Webb tokens don't have to worry about headers or anything
like that and site will react up everything.
We just have to go through the flow and boom we are magically logged in.
So in this case again I'm going to say you know what this sounds like it's crazy it sounds like it's
very complicated.
But we decided to take the approach we did because it was a very easy straightforward approach.
So again I really stand by the decision we made.
OK.
So this was a big issue number one big issue number two and this issue is nearly identical in nature.
OK.
So basically identical but it's just slightly different topic.
So again let's imagine that we are in the browser on localhost 3000.
If we are in the browser at localhost 3000 and we attempt to make some type of Ajax request to a server
also located at local 3000.
The browser says OK fantastic.
No issues here whatsoever.
Go ahead make your request.
Everything is A-OK.
However again as the browser security feature if we attempt to make a request from localhost 3000 we're
like we are visiting local was 3000 in the browser and we attempt to make a network request over to
a different domain or a different port that is counted as what we refer to as a course request core's
is short for cross origin resource sharing.
And if you've been doing web development for a while you've probably at least seen the error message
and probably done some endless googling on how to fix it.
I would bet you know that it's something that most web developers usually fall into eventually they'll
eventually see a course or quest and they'll eventually do some googling to figure out how to get around
it.
So this is another issue that is very closely related to this cookie stuff.
When we are in the browser at Domain Local 3000 we can make free Ajax request to the same domain no
issues whatsoever.
Everyone's happy.
As a security feature again 100 percent security related here.
Hundred percent security related.
The browser assumes that if you're at the domain local host 3000 and you make a request to a different
domain the browser assumes that you are trying to do something malicious like they assumed that the
browser assumes that it accidentally loaded up some bad javascript you know some malicious javascript
and something bad is attempting to make or request over to a different domain.
So the entire idea behind course again it is entirely a security issue that the browser places are a
security issue that the browser places upon request that you try to make from it.
Now again I can't say enough.
Yes we could have got around this.
We can configure this local host 5000 server this express API that we put together.
We can configure it in such a way that it says to the browser Hey browser you know what you're making
across urgent request but that's totally fine.
Come on in browser.
It's safe.
It's completely fine.
Allow the request here's the Jaison you looking for.
Here's the information.
And so again I'm going to say to you a second time we could have worked around this.
We could have solved this issue.
Totally possible but by not having to worry about making requests to this separate domain because we've
got the proxy here.
Everything is fine and it just works out OK.
And so just to make sure things are really clear let's kind of review why we don't have to worry about
cores in our setup.
So again it all comes down to the proxy in the development world.
Whenever we make a request from the browser we are going to make the request to localhost 3000 slash
API slash whatever that will be sent to the proxy.
The proxy will then forward the request onto the Express API the API sends a response back and in that
it's communicated back to the browser as far as the browser is concerned.
It only ever made a request to localhost 3000 and it doesn't think that course is even remotely an issue
here.
Even though the server actually is being run on local's host 5000 which would qualify as a chorus request.
So again the proxy really saves us in development mode.
Now in production again same thing as before when we are in the production world the browser is going
to see in the address bar by Daut Heroku out dot.com or whatever you're randomly generated thing here
is.
And so when we make an API request from the browser while the browser is at rock wrapped dot com and
we make a request back to our express server which is located at Heroku outcome is the same domain.
So again cores are not an issue just like cookies were not an issue as well.
Okay.
So hopefully at this point I've given you at least a little bit of a better sense why we chose to not
necessarily take this approach from the get go.
Now again I want to say one more time.
I have advocated for this approach in other courses of mine.
One of my other courses I explicitly show how to set up a server with this time type of setup.
But just to give you you know a little bit of variety here.
So you something different make sure that you could use create re-act out effectively all that kind
of stuff.
We're taking this other different approach.
All right so now we get into the real deep stuff.
This is the last thing we talked about in the section if you want to feel free to take a pause right
now pause the video grab a drink come on back.
This is the last thing.
And in this last this is maybe the real critical part.
I don't know this is the part that I personally think is important.
We're going to walk through the entire flow of our application with the proxy involved.
So by going through flow it's getting really nasty.
I promise you but you will get a much better sense of exactly what the proxy is doing.
You'll get a better sense of what the browser is doing with the Google API.
You know all this kind of stuff.
So we're going to walk through it in the development development mode and then we will also walk through
it in production as well.
So again before we do this remember this is an optional video so if you're tired of hearing you talk
about this stuff pause a video.
Move on.
Totally fine.
I am not offended.
Trust me.
OK.
So let's get to it.
So you're going to love this diagram.
Seriously.
Yeah.
Right.
Here we go.
So this is how the proxy is working with our express API in the development world.
So the very top we've got our browser.
Here's the crate re-act app and the proxy here is our express API.
And then over here we have Google.
So we're going to walk through this flow step by step together to give ourselves a better sense of what
the proxy is doing and how some of this stuff just seems to like magically work.
Now before we go through the flow one very critical thing I want to remind you about remember that if
we ever specify a relative path like anywhere inside of our application like anywhere anywhere anywhere
the browser will automatically assume that this relative path actually means whatever the current domain
is.
Slash author slash Google.
That that path or that domain being a pretended onto these relative path right here is extremely critical
to understand as we go through this flow because is what makes everything really work very nicely.
So just remember that fact the browser will automatically prepend on the domain.
OK.
Let's do this.
Honestly it won't be that bad.
We've really covered the details of everything that's going on here already.
And so it's kind of like reinforcing some of the stuff so really it's not that.
OK.
So here we are we're in the browser right here.
Let's assume that the browser the user is out like localhost three thousand they see some link that
says as an H ref slash or slash Google.
Now when the user clicks on that link the browser sees that it is a relative path.
And so it's going to automatically prepend on local host Colin 3000.
So we're going to turn to local host 3000 slash off slash Google.
The request is issued.
So the browser says OK looks like we're navigating.
I'm going to go to this other location.
Going to go to this other route.
So it goes to the Create react rate Sumeet create re-act server and the proxy that sits inside of it
that proxy sees the request incoming to slash or slash Google when that request comes in the proxy automatically
looks into its package not just on file.
And it says this person is trying to make a request to slash or slash Google.
Do I have any settings around that route.
And of course yes we do.
The proxy says hey you know what create react up I'm the proxy.
I got this.
I'm going to take it from here.
So create.
Create a proxy sees that incoming request it decides that it is responsible for that request and it
tells that request to just sit.
It says Hey browser hold up for a second I'm going to figure out what to do with you.
The proxy then takes that exact request and copies the entire thing.
Like word for word.
Line for line.
It takes the exact same request and completely copies it and then takes that request and sends it on
to the new route that we had specified inside of the router configured as the proxy configuration.
So in this case it's going to take that copy to request and send it to localhost 5000 slash Auth. slash
Google.
So now the request from the browser is still sitting there still pending the proxy has sent this request
out to the Express API the Express API picks up the Reclast it says oh hey OK I see that you're trying
to auth no problem to get into our flow.
Please go over to Google dot com.
So you're going to go over to Google dot com.
And after that here is your call back.
You are out the callback.
You are.
Remember the thing that we had specified in the Google strategy.
So where's our Google strategy right here passports.
So here's our Google strategy we had specified that Colback you are l with a relative path.
So we said when you come back go to auth slash Google slash callback to so that response is formulated
up by the Express API it sends it back to the proxy.
The proxy takes the response it takes the pending request that was sitting there from the browser and
it sends it on back.
So it sends it back to the browser.
And now the browser is over here thinking oh ok.
I guess I need to go over to Google.
That's what this request that I just made.
Little does the browser know that the proxy actually kind of copied and did all this stuff so the browser
thinks OK I need to go to Google right now.
I'm going to go to Google.
And then on return I'm going to go to slash Auth. slash Google slash callback.
That is a relative route the relative route is going to be automatically turned into localhost three
thousand local over 3000.
So when we get that call back when we get redirected by Google Google is going to attempt to send us
back to localhost 3000 not 5000 not the Express server.
OK.
So that's kind of like real piece of magic right there.
Number one that's totally awesome for us.
That really works out well.
So the browser continues on to Google over Google.
The user sees that consent screen it says hey these the guys these toll like whack jobs want to get
access to your profile.
Is that OK.
And the user says yes that's OK.
So Google then says OK authentication done it's time for you to go back to localhost 3000 slash off
slash Google slash callback.
So we go back to that address and remember this time around when we come back from the Google flow.
We also put our code in there as well.
The code is in the URL from the Google API.
From the Google flow.
So we get sent on back.
You get sent on back and request again at local has 3000 runs into the proxy.
Again same floatable before the proxy sees this incoming request to local host 3000 or slash Google
slash callback that will be picked up by the same rule right here.
Even though it says you know slash Colback it's still going to be picked up by this request right here.
So that proxy is going to say okay I'm in charge of this route I'm going to take things over it copies
the request.
It sends a request to the API our API takes the profile or it takes the code that was new or l it goes
and fetches the profile.
It does all that fancy stuff that we spoke about endlessly.
And then when everything is said and done it sends back some response that says OK you're logged in
now here's your cookies.
Hope you're happy you're logged in.
Everything's fine.
So the Express server then responds back and says OK.
Everything looks good sends a response response back to the browser.
And everyone's happy.
Now the one thing that this diagram does not correctly have is on a diagram I'm saying that after the
Express API collects the user details sets the cookie does all that stuff.
I'm saying that it tells us to go back to the route of Fort sastra here.
We have not actually done that just yet and we haven't actually set that up inside the server but we
will very shortly.
So at the end the server is essentially going to say OK I've got everything go back to forward slash
or essentially do a redirect and when the redirect is sent back to the browser again the server the
Express API is going to say just go to forward slash or like the route route in our application.
And again the browser is going to interpret that as meaning go back to localhost 3000 slash because
it's going to automatically prepend on the current domain.
OK so that's the flow that saw all this stuff works.
Again the entire linchpin here is the fact that the browser automatically pends on the domain to any
relative route.
That's what makes things just work like really nicely for us.
So now we've gone through the debt flow very quickly I want to go through the production flow but it's
much more simple much more straightforward.
So let's do it very quickly.
Let me zoom in just let's do 150 with.
Okay.
So again we're up at the browser.
Again this is production.
That means we no longer have to create re-act out server.
So everything is just running on our like we get in here the buy you dog Heroku app dot com domain.
So there's some around in production the user clicks on that button that says Take me to auth slash
Google dot com and you know what I actually put in my notes here I said that at this point we're on
e-mail dot com.
It doesn't really make a difference let's assume that we buy a domain name and associate it with our
Heroku account.
So let's just assume we are at email dot com.
So we are at e-mail dot com.
We click the Start button the start button has a link where not start but you log in with Google.
It has an a trough of slash slash Google the browser will automatically prepend on email dot com.
So the browser gets sent onto our express API.
Remember in production we no longer have to create re-act up server.
We no longer have the proxy.
And so everything behaves much more predictably.
The request goes to the API.
The API says oh you're trying to show off.
OK.
Go over to Google when you are done with Google.
Go back to slash slash Google slash callback.
So the browser then says OK everything looks good on return I'll go to you slash author slash fool slash
callback.
We go to Google a lot.
It's complete.
We go back to e-mail dot com because that is what the browser decided to go to when it prepended the
URL or the domain onto the link.
We could then go back to the Express API.
We serve up the code that is included in this callback.
You are all right here.
So really this would have you know the code equals 1 2 3 whatever our express API fetches the user profile
sets the cookie and then eventually dumps the user back at the root route of our application.
OK.
So I'm talked out I'm not going to lie.
I'm talked out at this point.
We have spoken.
How are Apple about how our application works in the development world and in the production world at
this point you might be thinking you know what Stephen this development or this server architecture
that we're using is ridiculous.
Why do we have to deal with any of this stuff at all.
Well again let me point you back to exactly what we said at the start of all of this.
We had originally said that to get everything to work all we really have to do is set this proxy right
here and then everything just kind of magically happens for us.
It all just kind of works.
But in the real world you know what's really happening is this very complex flow and this crazy series
of operations that works so crazy in tandem with the flow and it really relies upon these very specific
pieces of web architecture how the browser works and all that kind of crazy stuff.
So if you are now sitting here thinking seaven this architecture is crazy again.
You know what.
It works just fine.
It's super smooth.
You don't have to worry about all these behind the scenes details.
But at this point I hope that you have a much better sense of how our application really works and how
these two servers really behave together.
In addition I hope you have a better sense of some of the reasons that we decided to go with this flow
at all.
You know we got to completely skirt all these issues with corps requests.
We got to take advantage of using cookies for authentication which is very arguably the most secure
way of handling authentication and arguably more secure than using Jason Webb tokens and manually passing
passing them around inside requests.
So we took this entire architecture for a good reason.
And we only decided to kind of dive into what's going on behind the scenes so that we would get a better
sense of what's going on.
So I hope at this point that you better understand what our server is doing and I hope you've got a
much better sense of how we've really put everything together.
So now we've gone through all this stuff we are really done with a lot of the very complex theory in
this course.
There's not a lot of other superintends stuff like this we have to get through from here on out.
It's mostly going to be about building the application.
I will say that the there is like the one last thing that we have to do around production or deploying
to production with create re-act out.
So we might kind of revisit a couple of these topics when we deploy our application to production the
next time but we definitely won't do it as in-depth as we have now.
So with all this done with all this understanding of the way.
Let's take a break continue the next section and continue working on our app.