In the previous step we introduced "getServerSideProps",
which is a way to fetch new data for every request.
Although I also mentioned that
in most cases it's better to use "getStaticProps"
along with a "revalidate" timeout,
if your data changes but not very often.
While if you really want to get
fresh data on every request
you can also do that on the client side,
using what we called "Option 2".
In fact in this video I want to have another look
at our "index-2" page.
One of the possible downsides I mentioned
about fetching data on the client side
is that this way
the browser calls the CMS API directly,
which means we need to make this API
visible to everybody,
rather than just to our own servers.
And that also means that
the data sent to the browser
includes many fields we don't actually use.
The CMS API is designed to serve
many possible clients,
so it's not optimised for our specific application.
Now, Next.js does provide a way to
avoid both these problems,
even when fetching data on the client side.
And the way to do this is to use "API Routes".
If you remember we saw an API route
in the initial project generated by Create Next App.
To create an API route
we need a special folder inside "pages",
called "api".
And inside here we can create a route,
simply by adding a JavaScript file,
for example let's create a "products.js".
So this is similar to how we create pages,
in that we use the filesystem-based routing.
But an API route is not a page,
where we write a React component
that is rendered to HTML.
Instead in this case we write a "handler" function
that operates directly on
the HTTP request and response.
Here "req" stands for "request"
and "res" for "response".
Instead of returning JSX elements
like in a page component,
a handler function typically returns some JSON.
For example, on the response object
we can call the "status" method
to return the HTTP code 200,
which means OK.
And then we can return some data
by calling the "json()" method
with a value, for example an empty array.
If you ever developed server side code in Node.js
using a framework like Express,
this should look familiar to you.
If not, don't worry,
I'll explain everything as we go along.
Once we have the "handler" function
we need to export it
as the "default" export for this module.
And at this point we can call that API route
just like we call the CMS API,
so I'm going to use the REST Client.
But the API route runs in the Next.js server,
so that's on port "3000",
which is of course the same address
we use to load the pages in the browser.
And the path for the new route
is "/api/products".
Because "products.js" is under the "api" folder,
and Next.js still uses its filesystem-based router
even for API routes.
Now, let's try sending this request,
And you can see that we get a response
with a status of "200 OK",
and in the body we can see
an empty JSON array
just like we wrote in our handler function.
So we can use API routes to
effectively create an API
inside our Next.js app.
Now, you may be asking yourself
what this has to do with
fetching data on the client side,
which is what I started this video with.
That's because one way to use API routes
is to effectively proxy calls to another API,
like our backend CMS.
So we could have our client side code
call this API route
to get the products data from the CMS,
but including only the fields we need.
Now, we already have a "getProducts" function here,
to fetch the data from the CMS.
So let's call it from our API route.
And for that it's better if we make
this function "async"
so then here we can get the "products"
by awaiting the result of calling "getProducts".
At this point we can simply
serialize these products to JSON in the response.
So this API route is effectively acting
as a proxy for the CMS.
Let's see what happens now
when we make a request.
You can see that our API route returns
all the 6 products coming from the CMS,
but at the same time it transformed the data
so that each product only has "id" and "title" fields.
So we are converting the response from the CMS
into a structure that's more suitable
for our specific application.
This approach of having an intermediate API
that adapts the data coming from an external API
is sometimes called the
"Backend for Frontend" pattern,
in the sense that this API handler is a backend
designed specifically for our frontend,
as opposed to a general purpose backend
such as the Strapi CMS.
Anyway, as a final step
let me add a log statement here
so we can see when this handler is invoked.
Let's go back to the REST Client,
showing the server logs.
If we make a request now,
we can see that the handler was called.
And if we make another request,
it will call the handler again.
So the handler function is called
every time we make a request.
This is probably obvious,
but in this respect an API route
works like the "getServerSideProps" function.
Ok, so now that we have this API route,
in the next video we'll see
how to call it from our frontend.