Now to allow this frontend axis as explained,
we have to go to the backend code,
because we can only change it there.
And there it's an app.js where I wanna add a new middleware.
There are third-party packages we can use,
but here we will write our own middleware
so that we fully understand how course works.
For this, I'll add a middlewares folder,
which is optional though,
in which I'll add a cors.js file.
And in there, I'll add an enableCors function,
name of CORS is up to you, which I will export.
And now, before we add any logic here,
back in app.js, I wanna import this function.
So here, I'll add enableCors
and get this by requiring middlewares cors.
And then let's say
here at the very beginning, actually,
I will
call
enableCors.
Whoops, not like this,
instead like this.
We point at enableCors, I should say,
because that's a function that should be executed by express
for every incoming request.
And now it's inside this enableCors middleware function,
where I wanna add those response headers
I just showed you on the slide.
So here we have a request and a response object
and this next function as an all middleware functions.
And then
we can use the res object here
to call a set header method.
That's a method provided by express js,
the backend framework we are using here
to add a header to the response.
Now set header wants two parameter values.
The first value is the header which we wanna set.
The second value is the value for that header.
Now, the first header which I wanna add
is this Access dash
Control dash
Allow Origin header.
With that, we control which over domains
we wanna grant access here.
And here, you could be specific
and say something like your-page.com
should be able to send requests.
But here, I'll just add a star, which means any of our page
will be allowed to send requests.
And of course, if you're building an API
just for yourselves, this might not make sense.
You might wanna specify a specific domain in this case,
but I wanna show the wildcard case here as well,
because if you would be building an API like the Stripe API,
that should be accessed by a lot of our developers
working on a lot of our projects,
then you might wanna offer this generic type of access here.
Now, next we add another header here,
and that would be the
Access dash
Control dash
Allowed dash
Methods header.
By the way, it does not matter in which order
you add those headers.
Now here, we specify which HTTP methods we wanna allow.
Now, in our case, our backend here, of course, has routes
for get, post, patch, and delete.
So it makes sense to allow these four methods.
So here I'll add GET, written like this, comma POST,
comma PATCH,
comma DELETE.
That is how you can unlock methods, which are now allowed.
I will also add a fifth method here,
but just the options method.
This is not a request which
we'll send ourselves in any place
and we'll also not handle it ourselves on the backend,
but it is an automatically sent request,
which the browser will send when you use Ajax requests,
where it basically evaluates whether the request
it really wants to send,
for example, a delete request will be allowed by the server.
So we should also add options here.
Now, last but not least, I will also add another header
and that's Access dash
Control dash
Allow dash
Headers.
And with that, we control which headers
might be added by the client that sends a request.
So now we're talking about the request headers
that we wanna support.
Now, a bunch of default headers are always supported
here, I just an additional one
to allow the contents dash type header,
because that is a header which I do is set explicitly
on the frontend for some of my requests.
For the create to do request,
I set the content type header to application json,
hence, I wanna allow content type on the backend here.
Now, there also are other headers,
which you could check out.
Other access control heteros
you could add to the response
and attached you find a link to an MDN page
with more details about cores
and the heteros you can add,
but these are the three main headers, which you want to add,
if you want to unlock your API for it being usable
by upper decoupled frontends.
Last but not least, we have to call next,
because of course the request which we handled here
should still be allowed to travel on,
and for example,
reach the final route handler that should handle it.
But now with that middleware added
and also added here in app js.
If we now reload our frontend page,
we should see to do it here.
If you have any introduce on the backend,
if you don't have any yet,
you can of course add a new to-do here like this.
And what you'll notice if you add on you to do
is if you watch this refresh icon here,
in the top left corner,
as I click save, it doesn't change.
It never spins or changes to a cross,
because this page never reloads.
Instead here, we really handle all of that
just from inside the client side, JavaScript code.
This new Dom element here at the bottom
was added with client side JavaScript code.
I can also update to do's here or delete to do's.
And if I reload the page,
an idea for trigger load to do's again,
you'll see that really was the case,
the Arbor to do's,
which I updated on the Dom before,
still are gone or updated.
And that's now this decoupled frontend,
which is entirely JavaScript driven
browser side JavaScript driven
for the reasons I explained before
and that is how we can connect it to our backend API,
which now also shows us one possible use case for building
such an API.