[Maximilian Schwarzmuller] So we're now fetching data
directly on the server inside of the React Server Component,
and that's better than doing it on the client side.
But if you have a situation as we have it here,
where you also own that separate backend
that provides the data,
you have to ask yourself why you split your application
into two servers in the first place.
Why do we have a separate backend server here?
Why don't we instead directly reach out to the database
from inside our Next.js application?
And of course, there might be reasons for that extra server,
but here in our demo, in this scenario,
there is no such reason.
And hence, as a next step,
we can even get rid of this fetch call here
and of sending this extra HTTP request,
and instead move that database
from that separate backend server into our Next.js project.
So I'll just move that data.db file
into this Next.js project
and add some code to that Next.js project
that does allow us to directly reach out to that database.
For that, I'll stop that backend server,
and then go back into my root Next.js project folder.
And I'll start by adding an extra dependency
that will allow us to reach out to that database.
And that dependency is called better-sqlite3.
That's a package that allows us to easily interact
with a SQLite database,
as we have it here with that data.db file.
Then as a next step, I'll go to this lib folder,
and there, the news.js file,
where we're currently using the dummy news.
And I'll keep that around for now
so that the entire app doesn't break suddenly.
But I'll also add a new import here,
and I'll name it SQL and import this better-sqlite3 package.
And then here, I'll initialize access to my database
by creating a db variable or a constant,
and by calling this SQL thing I'm importing
from better-sqlite3.
And then we pass a path
to our database file seen from the root project folder
to this function.
So my database file is called data.db,
so it's data.db which I add here.
And yes, it's not in the same folder as the news.js folder,
but here, you add a path
that is relative to the root project folder,
and data.db is stored in that root project folder.
This will then give us access to that database.
And now I'll start with this getAllNews function here.
And instead of returning my dummy news here,
I wanna return news that are fetched from that database.
And for that, we can use that db constant here
and call prepare to prepare a new SQL statement
that should be executed,
and simply select everything from news.
And of course, you don't need to know SQL
to follow along with this course.
We'll just write some basic statements and commands here,
and you can simply copy and paste them.
You don't need to know SQL.
Using it is, of course, absolutely optional
when working with Next.js.
And I'm just using it here
because I chose to use SQLite as a demo database.
Now, we then have to call the all method
on this prepared statement
to essentially return and store all the returned data
in that news constant.
So that will then be an array of news items
that are fetched from that database.
And these news items will have the same structure
as the news we had in the dummy news constant,
because in that backend code where I had the code
for initializing that database,
I made sure that the same structure was set up there.
So with that, I'm getting all the news,
and now we can return them
because the nice thing about this better-sqlite3 package
is that it's actually giving us asynchronous API.
So this does not even yield a promise
which we have to await.
Instead, we can just execute the code like this
and will instantly get the news that were fetched,
which of course is pretty convenient
because that means that this is all we have to do here
in order to fetch our news.
And in page.js where we need those news,
we can now get rid of all this data fetching code here,
and instead just get our news by calling getAllNews,
which is imported from that news file.
And if we now save that,
and we reload,
boom, our news are there again.
And of course, hopefully, unsurprisingly,
they are there in the code that was rendered
on the server as well.
And now we skip that extra backend
and that extra HTTP round-trip.
And instead, we directly fetch data from the data source,
which in this case is a database,
but which could also be a file or whatever.
And we directly fetch data from there
and use that in our components.
And that's, of course, a really nice feature
which we can only use
because we have those React Server Components,
because that database, of course, lives on our server.
This code would not work on the client side
because the client side doesn't have access
to that database.
And it shouldn't for security reasons.
But since we're in the React Server Component,
this code will only ever execute on the server,
unlike client components
which also execute on the client.
But this code only executes on the server,
and therefore we can safely reach out
to that server site database and get our data from there.