To see this in action,
I can use this Live Server extension,
which we used earlier in this course already,
to open this page.
Now, if you do that, you will notice
that the page that loads greets you with an error.
And if you open the developer tools,
you should see an error message there.
We can ignore the first one about the favicon.
This is not important to us.
Here, the browser just tries to fetch a little icon
that's shown next to the title here in the tab.
We can ignore this.
But the more important error message is this one here.
Access to fetch at this domain we're sending the request to,
from origin, this domain here
on which our front-end code runs,
has been blocked by CORS policy, and so on.
Now, what is a CORS policy?
And what's blocking our request here?
Now, CORS stands for Cross-Origin Resource Sharing,
and it's a browser mechanism that allows servers
to indicate which origins, which simply means domains,
may access the resources provided by the server.
Now, it's super important to keep in mind
that it's a browser mechanism.
As you saw before with Postman,
where we interacted with the same API,
we got no errors there.
We could use the Postman client without issues.
Now that we're trying to use a web client,
a different page running on a different server,
we are getting errors
because it's a browser-based mechanism.
It's the browser that's blocking the request here,
not our server or anything like this.
Now, it's this browser mechanism,
and it's kind of a security mechanism,
but since it only applies to the browser
and over clients can send requests,
it's not really a security mechanism
on which you should rely.
The idea is that if you're building a site,
you can't just start using web APIs
or services provided by other users, other developers
unless they unlocked their APIs and services
for usage by other sites, by other origins therefore.
Now, by default, if you have a server A,
let's say localhost:3000, which is our back-end server,
then the resources of that server can be requested
by this same domain only, so that would work.
So if we had a front-end running on server A,
that front-end could send JavaScript driven requests
to the routes, to the end points provided by server A,
and we could request the data from there.
That's what we did before in the course
when we, for example, used Ajax in the online shop.
There, we had no problems sending requests
with browser-side JavaScript because the request was sent
by a page served by the same server
as was used for serving the back-end.
Now, here we have a different case.
We now have a different server that serves the front-end,
on localhost:5500, for example, which is localhost,
but since it's a different port, it's a different domain.
And of course, you could also translate
these localhost domains to real domains
if you would host these websites on real hosting providers,
like example.com and mypage.com.
So we have two different domains here
which are hosting two different sites in the end.
Server A is hosting the back-end in our case here.
In that case, server B, by default,
can't request the resources provided by that server.
That's what we're seeing here in the browser
with this error message.
This is not allowed.
Now, that's the default.
As a developer, you can change it though,
but only as the developer of the back-end code,
because the idea is that the browser ensures
that other sites can't just start using APIs
by other developers without the permission
of those developers.
Therefore, of course, it's the developers
of the back-end of the API
that have to give those permissions.
Hence, you can only change CORS behavior
in the back-end code.
And you can change it there
by setting different response headers,
and only by setting different response headers.
You can set any request headers you want
on the front-end site that wants to access a resource.
You can't unlock it there.
Only the back-end can allow access
by setting proper response headers.
And there, we got three main headers
which we can set on the back-end,
Access-Control-Allow-Origin,
Access-Control-Allow-Methods,
and Access-Control-Allow-Headers.
Now, with Access-Control-Allow-Origin,
we control which origins, so which other domains,
may request resources.
And by default, it's only the domain
which provided the resources.
That's what I explained a few seconds ago.
We can change it on the back-end though.
We can then also set which HTTP methods we wanna allow,
GET, POST, PATCH.
We can control on the server
which kind of requests we wanna allow
to be sent to our back-end API.
And we can also set which extra headers,
besides some default headers which are always allowed,
we wanna allow on the back-end.
Now, that's the theory.
Let's now implement this,
and let's see how we can make our front-end here
work with our back-end API.