Brand bad, and once we have looked at how we can implement the course package to fix our error.
Now let's take a look at the second approach.
The proxy and here's why you see at the moment.
Once we host this somewhere, the server I'm talking about, once we push this up to production, any
front and application can access the data, the API and there's times when you want that.
For example, I have coarse API, which essentially is a resource for all my students in reactors and
JavaScript course, and it's just a bunch of straight up endpoints where you can get some juice on there.
So we're building the project and in order to practice on how to fetch data, javascript or react.
We're hitting these papers.
And of course, this one, yes, I want this one to be publicly available.
But when we're talking about our job, if I one.
If we think about it, do we really want the back end server to be accessible from anywhere?
Like is there any need or only our front end application should have access to our API?
And of course, the answer is, well, kind of doesn't make sense that any front an application can
access our API only our front end application needs to have access throughout.
So that's point number one.
And if you're familiar with course, you're probably thinking, OK, buddy, you don't know what you're
talking about in the course, you can set up the origin so we can pass here some kind of configuration
option where only let's say our frontend can access the code and you're 100 percent correct.
You can set up the config with origin where you explicitly say which domain has access to your data.
But the reason why we're going to go with the proxy option is because it's going to solve more than
just this.
It's essentially will also allow us not to use the full URLs in the front and application.
So that's the second point where I don't want to use my full URL when I'm building the front end application.
I mean, I don't want to go with localhost 5000 and then refactor it to whatever production one.
Again, you can make an argument that you can set it up as a viable yada yada yada yada.
That's not the point.
The idea is that I want to do something like this where I go with four slash, especially if we keep
something in mind eventually, and I'm purposely not covering this in great detail, but eventually
we all use build script to build our production ready react application.
It's just going to be a bunch of static assets.
And then on the server, we'll use express static to serve it as a static asset.
And what that means, we can simply use for its lashes.
But at the moment, we kind of do that in the development, correct?
Again, I'm skipping a little bit ahead, but I'm not covering more details on purpose because I don't
want you to.
Confused what I want you to understand is that we solve both of our issues.
First in the front end will be able to use code like this where we just go with forward slash and whatever
is the endpoint, whether that is auth, whether that is jobs.
And hopefully you get the gist.
That's number one.
And second, we won't need to use the course package on our server altogether because eventually our
front end application, like I said, is going to be hosted on our server anyway.
It's going to be our static asset, so it will have full access to the API.