Original subtitles

So now we covered getStaticProps

and getStaticPaths and getServerSideProps

and I hope it's clear what these functions do

and why they exist.

They allow us to fetch data for pre-rendering those pages

So that we pre-render the pages with the data

instead of without the data they might need.

Now, up to this point,

we're only working with dummy data though

which is not actually fetched from anywhere.

Instead, we have this dummy array

or in the case of the meetupId page here,

actually hard-coded data

in that return statement.

And that's of course not realistic at all.

Instead, we do have this Add New Meetup page here

which would allow us to enter data for a new meetup.

And hence, we're now going to finish this app

by adding a real backend

with a real database where the data will be stored

and from which we then fetch it.

And this then also allows me to show you the last major

NextJS feature, which is added

by Next to your React apps.

NextJS makes it easy for us to build an API,

a backend API,

together with our front-end React app

in the same project.

For this, we can use another key NextJS feature,

called API routes.

API routes are a special routes, special pages,

if you wanna call it like this

which don't return HTML code, but which are instead

about accepting incoming HTTP requests,

also post patch, put delete requests,

whatever you need with JSON data attached to them

and which then might do whatever you need to do.

For example, store data

in a database and then return JSON data.

So you could say API routes allow you

to build your own API end points

as part of this next project.

And they will then be served

by the same server as your next app.

Now to add API routes, you add a special folder

in your pages folder, and that's a folder named API.

And just as the pages folder has to be named pages,

this folder has to be named API

and it has to be in the pages folder.

Then the NextJS will pick up

any JavaScript files stored in there

and turn those files into API routes.

So into end points, that can be targeted

by requests and that should receive JSON and return JSON

Now in this API folder, you can then again

add JavaScript files where the file names

will act as path segments in the URL.

For example, a new-meetup.js file again,

now here in the API folder.

Now, in those JavaScript files here,

you then don't create a React component function.

These API routes are not

about defining, rendering or returning React components.

Instead in there,

we will define functions which contains server-side code

because API routes will only run on the server

never on the client.

Decoding them will never be exposed to the client.

So we can also use credentials

in API routes without compromising them.

And those functions are then simply triggered

whenever a request is sent to this route,

so to /api/new-meetup here.

This would be the URL of this file

and if a request is sent to this URL,

it will trigger the function

which we have to define in this file.

Now often these function named handler

but the name is up to you,

the important thing is that it's exported.

So we export this handler function here

and this function will receive a request

and a response object.

You might notice from node.js and express.js.

The request object contains data

about the incoming request.

The response object will be needed

for sending back a response.

Now, from that request object,

we can get things like the headers or the request body

and also the request method, route a method property here.

This allows us to find out which kind of request was sent.

And we could, for example,

check if we are receiving having a post request here.

So if the request method is POST,

and we only execute the code in this if check,

if it is a incoming post request.

For other kinds of requests, we don't do anything.

So that would ensure that only post requests

to this route would actually trigger this code in here.

Then here, we can get our data by accessing req.body.

The body field is another built-in field

which contains the body of the incoming request,

the data of the incoming request.

And then we can do whatever we need to do.

Now this year will be the end point

for creating a new meetup.

And therefore it's probably fair to expect that this data

which we get contains a title, a meetup image,

an address and a description field.

After all, it's our page, our project, and our API.

So we can expect whichever data we need.

We will then just have to make sure

that we send the correct data when we do send a request

to this API route later.

But for the moment I do indeed expect

that we get some data out of this data,

so out of this request body

and I'll use object de-structuring here

and I expect to get a title, a image field,

an address field and a description field.

So these are the four fields which I expect to get

on the incoming request body.

And then we can store them in a database, for example,

and that's what we're going to do now.