Frontend Beauty
ESC

Type to search the knowledge base.

Data Fetching Patterns App Router

Fetch data in Server Components with async/await and fetch caching: colocation, parallel requests, and client fallbacks.

intermediate3 min read
  • nextjs
  • data-fetching

In the App Router, the default data pattern is fetch in Server Components with async/await. You colocate requests with the UI that needs them, leverage fetch caching/revalidation, and stream slow subtrees.

Docs: Data Fetching, Caching.

Server fetch

export default async function Page() {
  const res = await fetch('https://api.example.com/items', {
    next: { revalidate: 60, tags: ['items'] },
  });
  if (!res.ok) throw new Error('Failed to load');
  const items = await res.json();
  return <ItemList items={items} />;
}

No getServerSideProps. Dynamic functions (cookies(), headers(), searchParams usage) opt routes into dynamic rendering — see static vs dynamic.

Parallel and sequential

// Parallel
const [user, posts] = await Promise.all([getUser(), getPosts()]);

// Sequential when B needs A
const user = await getUser();
const posts = await getPosts(user.id);

Unnecessarily sequential awaits slow TTFB. Split into sibling components each fetching in parallel when independent.

Client fetching

Use Client Components + SWR/React Query when data is highly interactive, user-specific after load, or depends on browser-only inputs. Prefer server fetch for first paint SEO and secrets.

Mutations

Mutate via Server Actions or Route Handlers, then revalidate.

Interview out-loud

“I fetch in Server Components with async await and configure cache/revalidate on fetch. Independent data loads in parallel. Client fetch is for interactive post-load cases. Mutations invalidate with revalidateTag or revalidatePath.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Quick self-test

Explain the concept in 60 seconds, write a minimal code sample from memory, name one footgun, and point to the primary docs. If any of those fail, reread the worked example and rebuild it in a scratch file until the model sticks under interview pressure.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides