Data Fetching and Caching

A server component can await data before any HTML is sent, which removes the loading state, the effect and the extra round trip. What replaces them is a decision: how long may this result be reused, and when should it be recomputed?

That decision is caching, and it is the part of Next.js that causes the most confusion, because the same page can be built once at deploy time, rebuilt periodically, or built fresh for every request — and the difference comes from small options in your fetch calls rather than from anything visible in the markup.

Note before the examples: caching defaults have changed across Next.js versions. In current versions a fetch is not cached unless you ask for it. Check the behaviour for the version in your own project rather than trusting a sample found online.

// Cached until you invalidate it. Suitable for data that
// changes when someone edits it, not on a timer.
async function getDepartments() {
  const response = await fetch("https://api.example.com/departments", {
    cache: "force-cache",
    next: { tags: ["departments"] },
  });
  return response.json();
}

// Re-fetched at most once every five minutes. A stale result for up to
// five minutes is acceptable for a directory listing.
async function getEmployees() {
  const response = await fetch("https://api.example.com/employees", {
    next: { revalidate: 300 },
  });
  return response.json();
}

// Never cached. Correct for anything per-user or genuinely live.
async function getMyPendingApprovals(userId: string) {
  const response = await fetch(
    "https://api.example.com/approvals?userId=" + userId,
    { cache: "no-store" }
  );
  return response.json();
}

• cache: "force-cache" stores the result and reuses it indefinitely. The tag gives you a handle for clearing it later, which is what makes this safe to use for data that changes.
• next: { revalidate: 300 } sets a time window. After five minutes the next request triggers a refresh in the background, so no user waits for it — which also means one user may see the previous result.
• cache: "no-store" opts out. Use it for anything that depends on who is asking, and for data where being a minute out of date would be wrong.
• Any fetch marked no-store makes the route dynamic, which is covered below. This is the most common reason a page a team expected to be static turns out not to be.
• These options belong to the fetch, not to the page, so one page can combine a cached department list with an uncached approvals count.

import { notFound } from "next/navigation";
import { getAllCourseSlugs, getCourseBySlug } from "@/data/courses";

// Tells Next.js which values of [slug] exist, so it can render
// each one during the build instead of on demand.
export async function generateStaticParams() {
  const slugs = await getAllCourseSlugs();
  return slugs.map((slug) => ({ slug }));
}

export default async function CoursePage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const course = await getCourseBySlug(slug);

  if (!course) notFound();

  return (
    <article>
      <h1>{course.title}</h1>
      <p>{course.shortDescription}</p>
      <CourseOutline modules={course.modules} />
    </article>
  );
}

• The returned array is one object per page, with keys matching the dynamic segments. Twelve courses means twelve pages rendered during the build.
• The property values must be strings. A number will not do, even for an id — convert it.
• A slug that was not returned is still handled: by default Next.js renders it on demand the first time it is requested, then keeps the result. That is what makes this workable for content that grows after a deploy.
• The notFound() call still matters. generateStaticParams lists what exists now; it does not stop anyone typing a URL that does not.
• This pays off most for content with many pages and few writers. A catalogue of courses fits; a page showing each user's own progress does not, because there is nothing stable to build.