In the last section we spoke about how we want to only use relative links throughout everything on our
re-act front end but somehow have all those links magically for requests over to our express server.
Remember that part of the real issue here is the fact that if you only use a relative link the browser
will automatically append on or excuse me prepared on the current domain to the very front of the link.
And right now for us in the development world for our re-act server that is localhost 3000 which is
clearly not our actual back and server at localhost 5000.
So we fix that up by adding this little proxy thing right here.
We'll talk about what this is in just a second.
But before we do I want to flip back over to the browser.
Remember that we had gotten that redirect you or I mismatch over here.
So Google thinks that we're trying to go back to localhost 3 0 0 0 0 and slash off slash school slash
callback.
And it says that's not an authorized off location or off you know visit.
So we are going to open up our developer console and add this Lincoln as an authorized callback by adding
this link in.
It's just going to say only on our development side.
And this is really key.
We're only going to add in this additional route to the development side and we're going to say you
know what we can go to local's 3000.
We feel completely safe allowing that behavior because this is all stuff that's only in the development
environment.
So our back end or seeing our production configuration of our configuration we're not changing that.
The production configuration is still going to be super secure.
We're not making any changes on that side.
We're just being a little bit more flexible inside of development.
So to add on this additional redirect your I they give us this nice little link right here that we can
copy paste so we'll copy that thing right there.
I will open up a new tab.
We'll paste and flip on over there.
So they should automatically pull up our e-mail dash def project and specifically some of the redirects
you or I permissions around it.
Now this is taking a second to load up.
So while that's going I'm going to flip back over to the error message and I'm going to copy the link
that it said that we are trying to access because this is you or I that we want to wirelessed and say
is completely valid if someone tries to go here.
Now we'll go back over.
It looks like my console's is kind of moving slowly right now.
I'm going to scroll down to the authorized redirect your I.S..
I'm going to say that hey you know what.
It's totally fine.
If a user tries to redirect back to localhost 3000 again this is only for dev completely OK that we
are relaxing some of the restrictions here.
So make that change and then we'll click save and just let it do its thing.
Now remember that whenever we change a redirect you or I on Google as we just did right here or whenever
we add a new one it takes a couple of minutes for that new authorized redirector II to actually percolate
around Google's servers.
It's not an instantaneous thing.
It kind of takes a minute or two for a taxi like kick in and allow it to be permissible as a redirect.
So we're not going to test this again just yet.
We're going to talk about some other topic.
Give it a minute or two and it we'll come back and this link out again or test the oil flow again and
just make sure everything's working OK.
So while that is kind of doing its thing and percolating.
I want to talk a little bit more about that configuration that we added inside the package Jason.
Specifically this little proxy thing right here.
So we had said define some sort of proxy.
And if we read that it's as plain-English we can really read it as being make a proxy.
If anyone tries to visit the route slash off slash Google on our re-act server automatically for the
request on to localhost five thousand and then it is just kind of implied by this rule that if we go
to our slush Google we want to go to localhost 5000 slash off slash Google.
So we don't have to actually specify or kind of like spell this out.
In particular this proxy thing is going to automatically assume that when we are trying to go over to
this other domain it's going to carry over the route for us.
OK.
So let's talk about what's really going on here and why this is really working.
Now this is not really in-depth talk that I spoke about.
This is just kind of a little bit of high level.
Hey what does this kind of doing for us.
OK.
So we're going to check out a diagram.
So this is a diagram that really truly models what is going on with our server in the development mode.
So in development like running on our local machine when we are running our application like our server
for the re-act side and our server for the express application on our local machine we can imagine that
there's kind of like these two distinct layers.
Side of our application inside of our browser whenever we go to localhost 3000 in access our create
re-act up server.
It's going to return to us that bundle don't just file that contains all of our development assets like
the re-act library all the different components all that kind of good stuff.
And then any time that a reactor application needs any sort of data from our API or from our express
application that request is going to go to there create re-act up server to a proxy that is automatically
built in and included with create re-act up server that proxy is then going to take that request and
forward it on to the Express API.
And so that is exactly what we did right here with this little bit of configuration.
We said hey proxy that is included with create re-act up.
If anyone tries accessing slash slash Google on the re-act server right here automatically for that
request onto localhost 5000 and that's it.
That's pretty much the entire ballgame.
So for any different API route that we need to get access to from the browser from the Riak side of
our application we can make use of that proxy to automatically for the request on to the node or express
API.
And we can just put the route in.
Everything is going to work magically now I said this was the development mode.
So this is only for development and you might really notice that when we set up the proxy I used right
here local host 5000.
So you might be thinking.
All right Stephen that's great.
But what happens when we deploy the Roku.
Does that mean we have to go back to the proxy and also set up what was it like by you whatever dot
road to our dot com like what's going on here.
Does this actually work out.
Does everything actually fix itself.
And the answer is yes it automatically does everything for us.
We don't have to worry about it.
And here is why in production this is super important in production to create re-act apps server does
not even exist in production.
When we deploy our out Trochu everything is going to change in production before we deploy our application.
We're going to build our re-act project when we build our re-act project create re-act up is going to
take all of the different javascript files all the different CSSA files everything inside of here.
It's going to run web pack and Babel over all those files and then save a final production final build
of our application into this public folder right here.
Then whenever a user comes to our application running on Heroku we were only going to be running our
known express API and anytime someone comes to our application we will just automatically send them
back our h HTML file and the new Java the newly built javascript file that was just placed into that
public folder right here.
So I can even show you what this looks like in practice right.
We can kind of test this out very easily.
I can open up a new tab in my terminal and then change into the client directory.
Then inside of here I'll run the command and then run build when I do this to create re-act app application
is going to automatically create an optimized production build and then it will stuff it into our builds
directory right here.
So let's just give it a minute to do its thing when we get that finalized outputs.
That is it.
That's the entire re-act application.
We no longer have any need whatsoever to run the Create re-act application at all because the only thing
create racked up is really doing for us is giving us things like the live reload and some lynching's
some air checking all that kind of good stuff.
That's all the Create re-act out that server is doing and we don't need any that behavior in production.
So now OK it looks like everything is completed if we change into our public or excuse me it's not the
public directory my mistake it's the build directory right here.
So here's the build directory.
Here's our index HTL file.
Here's the static folder.
And here is our entire javascript application inside the japes folder.
So maynt J.S. Right here.
That's the entire application.
So when we move into production we no longer have to run the Create react app server all we have to
do is one time build our application commit this stuff deploy the application to Roku and then we leave
it up to the Express server to serve all of these different javascript files.
So that is why for all this proxy stuff that we set up we really only have to worry about making sure
that we set the proxy for our development environment because they create racked up server doesn't even
exist inside production.
Now you might still be wondering.
You might have this lingering doubt.
You might be thinking Well Steven if you're telling me that the Create locked up server doesn't exist
in production how do we do all this like Route real route to rewriting or how do we figure out the domain
and production.
Well remember that's the whole key.
That's the reason everything works out so well when we just use the relative route when we use relative
routes throughout our application the browser will automatically prepend on the current domain to this
address right here.
So in development when we access our create re-act up server at local host 3000 the browser is going
to think that this link wants to take us to localhost 3000.
And that's why we need that this proxy right here so that we will automatically take that request to
look lose 3000 and forwarded on to our express server at 5000.
But in production when our application loads up the browser sees that we are at Bayu dot Heroku out
dot com or whatever.
And so at that point in time in production this link right here will automatically turn into bayou or
whatever it is and whatever your application name is by you dot Heroku app dot com.
That's the beauty of all this stuff.
It all just works so perfectly between development and production.
So that's entirety.
OK.
So just one more time because that last point is like the real clincher.
Remember the entire idea behind the proxy right here is to rewrite requests from localhost 3000 slash
or slash Google to localised 5000.
We have to do that because in our development world we are running the two servers we've got to create
re-act out server and we've got to know Jesus server on the backend.
So any API request from the browser has to be proxied over to the Express API.
But when we deploy our application we no longer make use of create re-act up at all.
Create re-act app exists only.
So purpose.
No other reason besides this to give us a good development experience and help us make good re-act apps.
So in production we no longer use this server at all.
It completely just disappears.
So right before we deploy our app we're going to use create re-act out to build a production finalized
version of our re-act application and then when we actually go out to her Roku and serve everything
up we have the no new Express API which will automatically serve all those public assets like the bundle
J file.
It's actually called mange.
Yes but you get the idea.
They'll serve the main dodgiest file.
It'll serve our route a file all the CSSA all that kind of stuff.
And in development when all that re-act out stuff loads up inside the browser there's no longer a local
who's 3000 there's no longer our local host 5000 it's all being executed on her app dot com.
So all of these relative links that we have inside of our application automatically get rewritten by
the browser as Heroku app dot com slash Auth. slash Google or whatever other whatever other API routes
we have as well.
OK.
So at this point hopefully that all makes sense.
Ignacio right now hopefully that will make sense.
So this is the point at which I feel like hopefully you're getting a sense that the server architecture
that we picked here of having like to create re-act up and then the Express server right behind it.
Hopefully it feels like that all makes a lot of sense.
I'm hoping that's the case right now because to me this stuff all seems to be working like amazingly
beautifully in development we get create re-act up and all the benefits it brings but we don't have
to worry about any crazy configuration of routes or anything like that.
And then when we go to production to create re-act up server falls away and everything is kind of magically
works.
So at this point hopefully I've convinced you that our setup is completely reasonable and makes a lot
of sense and generally just works OK.
Now we're going to take a break.
When we come back in the next section we're going to kind of jump into the behind the scenes stuff where
we figure out how some this stuff really works.
And that is the very scary part that's the Partridge said you're going to say Steven Like why did we
pick this stupid server.
What's going on here.
So let's take a break.
We're going to come back next.
Our next section will do it talk and maybe it's not as scary as I think.
You know whatever.
So let's go into the next section and get to it.
So I'll see you in just a second.