Why Your Next.js 15 App Directory Build Fails with Fetch Calls in Server Components

Introduction

Next.js has become a popular framework for building modern web applications, thanks to its powerful features like getServerSideProps, getStaticProps, and server components. These features make it easier to build highly dynamic, scalable, and SEO-friendly applications. However, some developers make the mistake of using fetch to call their own API routes within these server-side functions, assuming it's a straightforward way to get data. Although this approach might seem intuitive, it can lead to build failures, performance issues, and other problems.

This article explores why using fetch to call your own API endpoints in server components or server-side functions is problematic, why such errors occur, and how to properly fetch data in Next.js to avoid these pitfalls.

The Common Anti-Pattern

A typical scenario that illustrates this anti-pattern might look like the following:

// Example: Fetching API route in getServerSideProps
export async function getServerSideProps() {
  const res = await fetch("http://localhost:3000/api/products/154783");
  const product = await res.json();
  return {
    props: { product },
  };
}

In this example, the developer is fetching data from an internal API route (/api/products/154783). At first glance, this seems to be a valid and common pattern, especially in server-side rendering (SSR) scenarios. However, several issues arise with this approach, which we’ll explain below.

Why This Approach Fails

1. Build-Time Failures

One of the most common and significant issues with this approach is build-time failures. Next.js’s build process does not spin up a server, meaning when you call fetch to http://localhost:3000, there's no server running to respond to the request. As a result, you may encounter errors like:

TypeError: fetch failed
    at node:internal/deps/undici/undici:13178:13
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Why does it work in development mode?

In development mode, Next.js runs a local server on localhost:3000 to handle requests. This server is able to respond to fetch calls, making them work in the development environment. However, during a production build (or when running a static build), there’s no active server running to respond to those API requests, resulting in failures.

2. Inefficiency and Overhead

When you fetch data from your own API routes, you're making an HTTP request from your server to itself. This introduces unnecessary overhead because:

• Even if the data is already available on the server, you're incurring the cost of a network request, including DNS resolution, routing, serialization, and deserialization.
• Your server is processing an HTTP request internally, which is inefficient and can add latency, especially when multiple requests are made.

Example of inefficiency:

// Fetching data from an API route unnecessarily introduces HTTP overhead
const res = await fetch("http://localhost:3000/api/products/154783");
const product = await res.json();

Instead of fetching from your API, directly querying the database or invoking the server-side logic that handles this request would be far more efficient.

3. Lack of Type Safety

Another significant issue with fetching your own API routes is the lack of automatic type safety. When you use fetch to call an API, you manually need to handle the response and ensure it matches the expected types, which can be error-prone.

Example:

const res = await fetch("/api/products/154783");
const product = await res.json();
// Manually handle the type of 'product' here

In contrast, if you directly call your server-side logic (like a Prisma query), you get full TypeScript support, ensuring that types are checked at compile-time.

4. No Automatic Access to Headers and Cookies

One important distinction between client-side and server-side fetch calls is that server-side fetch does not automatically inherit cookies, headers, or authentication data from the server context. If you need to pass authentication tokens, session data, or other headers, you must manually handle them, which increases complexity and can lead to bugs.

// Example: Manually passing authentication headers
const res = await fetch("http://localhost:3000/api/products", {
  headers: {
    Authorization: `Bearer ${authToken}`,
  },
});

This manual handling of headers and authentication makes the code harder to maintain and debug.

5. Cold Starts on Serverless Platforms

When deploying to serverless platforms like Vercel or AWS Lambda, invoking your own API routes with fetch can trigger a cold start. In serverless environments, the initial request might have to spin up a new instance of the server, which could introduce latency and delay the response.

Instead of triggering a cold start by making an HTTP request, you could invoke the server-side logic directly, avoiding these delays.

The Correct Approach

1. Call Server-Side Logic Directly

Instead of fetching your API routes, directly call the server-side functions or business logic that power them. This eliminates the need for HTTP requests altogether and improves performance and reliability.

// Example: Directly calling server-side logic
import { prisma } from "~/lib/prisma";
 
export async function getServerSideProps() {
  const product = await prisma.products.findUnique({ where: { id: 154783 } });
  return {
    props: { product },
  };
}

Benefits:

• Avoids build-time errors.
• Ensures full TypeScript support for type-safe operations.
• Eliminates HTTP request overhead.

2. Use Shared Utility Functions

If your API route and server component need to perform the same logic, extract that logic into a shared utility function. This approach ensures that the logic is DRY (Don't Repeat Yourself) and maintainable.

// Shared utility function for product fetching
import { prisma } from "~/lib/prisma";
 
export async function getProduct(productId: number) {
  return await prisma.products.findUnique({ where: { id: productId } });
}
 
// In getServerSideProps
export async function getServerSideProps() {
  const product = await getProduct(154783);
  return {
    props: { product },
  };
}
 
// In API route
export default async function handler(req, res) {
  const product = await getProduct(req.query.uid);
  res.status(200).json(product);
}

This reduces code duplication and keeps your logic consistent across both server-side functions and API routes.

3. Use API Routes for Client-Side Fetching

While you should avoid fetching your API routes on the server side, they are still useful for client-side data fetching, especially for dynamic or product-specific content.

import useSWR from "swr";
 
export default function ProductPage() {
  const { data: product, error } = useSWR("/api/products/154783");
 
  if (error) return <div>Error loading product data</div>;
  if (!product) return <div>Loading...</div>;
 
  return <div>{products.name}</div>;
}

This allows your client-side code to access API routes without the issues caused by server-side fetching.

Drawbacks of Fetching API Routes in Server-Side Code

1. Performance Overhead: The HTTP request/response cycle introduces unnecessary latency and resource consumption.
2. Build-Time Failures: Fetching during build time fails due to the absence of a running server.
3. Complexity: Manually handling authentication, headers, and cookies makes the code more complex and error-prone.
4. Reduced Maintainability: Encourages patterns that complicate debugging and code maintainability.

Conclusion

Fetching your own API routes within server-side code like getServerSideProps or server components is an anti-pattern that leads to inefficiencies, build failures, and increased complexity. Instead, directly call your server-side logic or use shared utility functions. By adopting these best practices, you’ll ensure your Next.js applications remain robust, efficient, and maintainable.

Additional Resources

• Next.js Data Fetching Documentation
• Prisma Documentation
• Vercel Serverless Functions
• React Server Components Guide