Next.js 14: Fetching Data

In this chapter
Here are the topics we’ll cover:

📚 Learn about some approaches to fetching data: APIs, ORMs, SQL, etc.
𝌏 How Server Components can help you access back-end resources more securely.
🌊 What network waterfalls are.
፨ How to implement parallel data fetching using a JavaScript Pattern.

Choosing how to fetch data

API layer

APIs are an intermediary layer between your application code and database. There are a few cases where you might use an API:

If you’re using 3rd party services that provide an API.
If you’re fetching data from the client, you want to have an API layer that runs on the server to avoid exposing your database secrets to the client.
In Next.js, you can create API endpoints using Route Handlers.

Database queries

When you’re creating a full-stack application, you’ll also need to write logic to interact with your database. For relational databases like Postgres, you can do this with SQL, or an ORM like Prisma.

There are a few cases where you have to write database queries:

When creating your API endpoints, you need to write logic to interact with your database.
If you are using React Server Components (fetching data on the server), you can skip the API layer, and query your database directly without risking exposing your database secrets to the client.

Let’s learn more about React Server Components.

Using Server Components to fetch data

By default, Next.js applications use React Server Components. Fetching data with Server Components is a relatively new approach and there are a few benefits of using them:

Server Components support promises, providing a simpler solution for asynchronous tasks like data fetching. You can use async/await syntax without reaching out for useEffect, useState or data fetching libraries.
Server Components execute on the server, so you can keep expensive data fetches and logic on the server and only send the result to the client.
As mentioned before, since Server Components execute on the server, you can query the database directly without an additional API layer.

Using SQL

For our dashboard project, we’ll write database queries using the Vercel Postgres SDK and SQL. There are a few reasons why we’ll be using SQL:

SQL is the industry standard for querying relational databases (e.g. ORMs generate SQL under the hood).
Having a basic understanding of SQL can help you understand the fundamentals of relational databases, allowing you to apply your knowledge to other tools.
SQL is versatile, allowing you to fetch and manipulate specific data.
The Vercel Postgres SDK provides protection against SQL injections.

Don’t worry if you haven’t used SQL before – we have provided the queries for you.

Go to /app/lib/data.ts, here you’ll see that we’re importing the sql function from @vercel/postgres. This function allows you to query your database:

You can call sql inside any Server Component. But to allow you to navigate the components more easily, we’ve kept all the data queries in the data.ts file, and you can import them into the components.

Fetching data for the dashboard overview page

Now that you understand different ways of fetching data, let’s fetch data for the dashboard overview page. Navigate to /app/dashboard/page.tsx, paste the following code, and spend some time exploring it:

In the code above:

Page is an async component. This allows you to use await to fetch data.
There are also 3 components which receive data: <Card>, <RevenueChart>, and <LatestInvoices>. They are currently commented out to prevent the application from erroring.

Fetching data for <RevenueChart/>

To fetch data for the <RevenueChart/> component, import the fetchRevenue function from data.ts and call it inside your component:

Then, uncomment the <RevenueChart/> component, navigate to the component file (/app/ui/dashboard/revenue-chart.tsx) and uncomment the code inside it. Check your localhost, you should be able to see a chart that uses revenue data.

Let’s continue importing some more data queries!

Fetching data for <LatestInvoices/>

For the <LatestInvoices /> component, we need to get the latest 5 invoices, sorted by date.

You could fetch all the invoices and sort through them using JavaScript. This isn’t a problem as our data is small, but as your application grows, it can significantly increase the amount of data transferred on each request and the JavaScript required to sort through it.

Instead of sorting through the latest invoices in-memory, you can use an SQL query to fetch only the last 5 invoices. For example, this is the SQL query from your data.ts file:

In your page, import the fetchLatestInvoices function:

Then, uncomment the <LatestInvoices /> component. You will also need to uncomment the relevant code in the <LatestInvoices /> component itself, located at /app/ui/dashboard/latest-invoices.

If you visit your localhost, you should see that only the last 5 are returned from the database. Hopefully, you’re beginning to see the advantages of querying your database directly!

Fetch data for the <Card> components

Now let’s fetch data for the <Card> components. The cards will display the following data:

Total amount of invoices collected.
Total amount of invoices pending.
Total number of invoices.
Total number of customers.

Again, you might be tempted to fetch all the invoices and customers, and use JavaScript to manipulate the data. For example, you could use Array.length to get the total number of invoices and customers:

But with SQL, you can fetch only the data you need. It’s a little longer than using Array.length, but it means less data needs to be transferred during the request. This is the SQL alternative:

The function you will need to import is called fetchCardData. You will need to destructure the values returned from the function.

Great! We’ve now fetched all the data for the dashboard overview page. Your page should look like this:

However… there are two things you need to be aware of:

The data requests are unintentionally blocking each other, creating a request waterfall.
By default, Next.js prerenders routes to improve performance, this is called Static Rendering. So if your data changes, it won’t be reflected in your dashboard.

What are request waterfalls?

A “waterfall” refers to a sequence of network requests that depend on the completion of previous requests. In the case of data fetching, each request can only begin once the previous request has returned data.

For example, we need to wait for fetchRevenue() to execute before fetchLatestInvoices() can start running, and so on.

This pattern is not necessarily bad. There may be cases where you want waterfalls because you want a condition to be satisfied before you make the next request. For example, you might want to fetch a user’s ID and profile information first. Once you have the ID, you might then proceed to fetch their list of friends. In this case, each request is contingent on the data returned from the previous request.

However, this behavior can also be unintentional and impact performance.

Parallel data fetching

A common way to avoid waterfalls is to initiate all data requests at the same time – in parallel.

In JavaScript, you can use the Promise.all() or Promise.allSettled() functions to initiate all promises at the same time. For example, in data.ts, we’re using Promise.all() in the fetchCardData() function:

By using this pattern, you can:

Start executing all data fetches at the same time, which can lead to performance gains.
Use a native JavaScript pattern that can be applied to any library or framework.

However, there is one disadvantage of relying only on this JavaScript pattern: what happens if one data request is slower than all the others?

Check out the video:

Support me: Like, Share and Subscribe!