Next.js App Router Data Fetching: Patterns That Actually Work

The App Router changed Next.js data fetching from client-side choreography into something closer to ordinary server programming — components can be async, fetch happens during render, and the old useEffect-dance mostly disappears. It also introduced genuine new confusion: when does code run where, what's cached, and why won't my button work? This post is the mental model plus the working recipes.

The foundational split: server vs client components#

Every component in the App Router is a server component unless marked otherwise:

// Server component (default) — runs ONLY on the server
export default async function PostsPage() {
  const posts = await db.post.findMany();  // direct DB access, no API layer
  return <PostList posts={posts} />;
}

// Client component — ships to browser, can be interactive
"use client";
import { useState } from "react";
export function LikeButton({ id }: { id: string }) {
  const [liked, setLiked] = useState(false);
  return <button onClick={() => setLiked(!liked)}>♥ {liked ? 1 : 0}</button>;
}

The decision rule is simple and worth memorizing: server by default; add "use client" only for interactivity — state, effects, event handlers, browser APIs. Server components keep secrets safe (DB credentials never ship), eliminate fetch waterfalls (data resolves before HTML arrives), and shrink JavaScript bundles to near zero. The common architecture: server components as the tree's trunk and leaves, thin "use client" islands wherever a click matters.

Fetching: just await it#

// Parallel: start both immediately
const [user, posts] = await Promise.all([
  getUser(id),
  getPosts(id),
]);

Data fetching in server components is async/await with no special API. Two patterns matter beyond the basics:

• Parallelize deliberately — sequential awaits stack latency; Promise.all doesn't
• Pass data down, not fetchers down — fetch in the highest server component that owns the data, pass plain props to children (client children included)

For data that changes rarely, tag it for revalidation control:

fetch(url, { next: { revalidate: 3600 } });      // ISR-style: fresh hourly
fetch(url, { next: { tags: ["posts"] } });       // invalidated on demand
revalidateTag("posts");                           // after a mutation

Mutations: server actions#

The App Router's answer to "how do forms actually save things" — functions defined on the server, callable from client components as if imported:

// actions.ts ("use server")
"use server";
export async function createPost(formData: FormData) {
  const title = formData.get("title") as string;
  await db.post.create({ data: { title } });
  revalidatePath("/posts");   // refresh cached views
}

// form.tsx — no API route, no useEffect, no manual refetch
import { createPost } from "./actions";
export function NewPostForm() {
  return (
    <form action={createPost}>
      <input name="title" required />
      <button type="submit">Publish</button>
    </form>
  );
}

This replaces an entire layer of boilerplate (endpoint + client hook + cache invalidation logic). The revalidate* calls are the piece people forget — mutations don't automatically update rendered pages.

Loading and error states as structure#

Convention-based boundaries replace per-page scaffolding:

app/posts/
├── page.tsx        // async data
├── loading.tsx     // automatic Suspense fallback while page streams
└── error.tsx       // catches render errors, offers retry

loading.tsx alone eliminates half of all hand-rolled spinner logic: any async work inside the segment triggers it automatically. For finer granularity, wrap slower sections in <Suspense> so fast content streams first instead of waiting for the whole page.

Caching: know what's cached and how to break it#

The App Router caches aggressively (rendered pages, fetch responses, route segments), which makes fast defaults and stale surprises. The levers, in order of use-frequency:

1. revalidatePath / revalidateTag after mutations — the daily drivers
2. { next: { revalidate: N } } for time-based freshness
3. dynamic = "force-dynamic" or no-store when something must never cache
4. Route segment cache: "no-store" equivalents at the request level

Debugging "why is this stale" starts here: identify which cache layer holds the stale copy (page? fetch? router?), then pick its designated invalidator. Caching tradeoffs apply at every layer — freshness always costs something.

The interview-ready summary#

• Default server components; "use client" only for interactivity islands
• Fetch by awaiting directly; parallelize independent requests
• Mutate via server actions + explicit revalidation
• Structure loading/error handling through file conventions
• Treat caching as layered, each layer with its own invalidation lever

Master those five statements with the recipes above and you're ahead of most production codebases — the App Router shipped faster than team habits could follow.

Related: App Router pitfalls · React rendering model · TypeScript contracts