Is any exception that client fetch should be used instead of server fetch?

[pamela-encora]

Related to the old Pages router I found an article explaining when it's recommended to use client fetch: https://nextjs.org/docs/pages/building-your-application/data-fetching/client-side. I would like to know if this is still valid for App Router.

The main issue is that server fetch requires the URL to be manipulated (pushing params to the URL) so that the server knows what data to fetch, but this triggers a server-side component re-render and re-renders the entire tree again.

However, doing the fetch on the client brings another question about the cache invalidation because if we use a server action to update this data, we'll need to do a workaround to manually invalidate the client cache.

[icyJoseph]

There'll eventually be an API to kind of do this, but often the roundtrip to the server still preserves client state and can be done in such a way that the result ends up streaming while the rest of the UI is resolved/rendered quickly.

[rehuux]

Great question. The short answer is: Client-side data fetching is still valid in App Router, but for different use cases than Pages Router.

Pages Router (Old):

Client fetch was recommended for:

· Authenticated content (user-specific dashboards)
· Search/filter results (real-time updates)
· Content that changes frequently

App Router (New):

When to use Server Fetch (default):

· Public content (can be cached & shared)
· SEO-critical pages
· When you can accept the URL-driven re-render

When to use Client Fetch (with useEffect or useSWR/react-query):

· Real-time dashboards (stock prices, live data)
· Complex filtering where URL params become messy
· Post-login personalized data where server re-render feels heavy
· When you want to avoid full tree re-renders (your main concern)

Your Specific Concern:

"Server fetch re-renders entire tree" → Yes, but Next.js 14+ is optimized. For most apps, it's fine.

"Client cache invalidation after server action" → Here's the pattern:

// Server Action
'use server'
async function updateData(formData: FormData) {
  // update database
  revalidatePath('/dashboard') // revalidates server cache
}

// Client component with SWR
const { data, mutate } = useSWR('/api/data', fetcher)

// After server action success
mutate() // instantly refreshes client cache

Bottom line: Both approaches still valid. Use server fetch by default. Use client fetch + SWR/React Query when:

1. You need real-time updates
2. URL manipulation feels unnatural
3. Server re-renders become a performance problem

The article is conceptually still valid, just the tools have evolved.

[GmanFooFoo]

hort version: there's no hard "use client fetch instead of server fetch"
rule in the App Router — it comes down to who owns the data and how
interactive it is. Server fetch is the default; client fetch is the
exception you reach for in a handful of specific cases.

Reach for client-side fetch when:

• The data depends on browser-only state — geolocation, viewport size,
  localStorage, scroll position. The server simply can't know these.
• You need high-frequency or real-time updates — live dashboards,
  presence, anything on a websocket or short polling interval. You don't want a
  server roundtrip per tick.
• The data sits behind a user interaction and shouldn't be in the initial
  SSR payload — type-ahead search, infinite scroll, "load more". Fetching
  these on the server just bloats the first response.
• It's personalized, non-SEO data where you'd otherwise opt the whole
  route out of caching.

For everything else — public content, SEO-relevant pages, anything cacheable
— a server fetch in a Server Component stays the better default.

Now to the two things you're actually running into, because thats where the
real answer is:

1. "Server fetch re-renders the whole tree when I change a URL param"

It feels that way, but it isn't the whole tree. Updating searchParams
triggers a soft navigation: layouts are preserved, and only the segments
that actually read searchParams re-render on the server. Two things make
that cheap:

• Read searchParams as low in the tree as possible, so the re-rendering
  server component is small. Don't read it in the root layout if only a table
  needs it.
• Wrap the data-dependent part in <Suspense> (or a loading.tsx) so the
  rest of the page stays interactive and the new data streams in. With <Link prefetch> the roundtrip is usually invisible.

So you get fresh server data without shipping the fetch to the client — the
re-render is scoped, not global.

2. "Client fetch + server action = cache invalidation hell"

Two clean patterns:

• If the data is server-fetched, call revalidatePath() /
  revalidateTag() inside the server action (with cacheTag if you're on Next
  16 cache components). The affected segment re-renders with fresh data
  automaticaly — no manual cache juggling.
• If the data is client-fetched via SWR / React Query, either call
  mutate() / queryClient.invalidateQueries() after the action resolves, or
  — cleaner — have the server action return the updated record and write it
  straight into the client cache (mutate(key, newData, false)). That skips
  the extra refetch entirely.

The thing that causes the "hell" is mixing the two: server-fetching the data
but trying to invalidate it from the client. Pick one owner per piece of data
and invalidate on that side.

TL;DR: default to server fetch; use client fetch for browser-state,
real-time, interaction-gated, or personalized data. The re-render problem is
solved by reading searchParams low + Suspense; the invalidation problem by
keeping each piece of data owned by one side and using revalidateTag
(server) or mutate (client) accordingly

[pamela-encora]

Hi
Thanks for answering.

Read searchParams as low in the tree as possible, so the re-rendering
server component is small. Don't read it in the root layout if only a table
needs it.

Do you mind sharing an example of this? Because this was what I thought was a right solution, but I was not able to make it work. It looks like the queryParams are only available to page.tsx component.

Another solution could be to get the queryParams in a client component (through useSearchParam), but the client would need to render a server component to do the fetch, which is not possible because server components can only be imported by server components.

Here's what I tried to do using the useSearchParams:

//page.tsx
export default async function MyPage(queryParams: Promise<{ id: string }>) {
  return (
    <>
      <MyComponentThatDoesNotNeedTheId/>
      
      // The idea here is to pass the server component as a parameter to be latter used by a client. 
      // But the issue is that I already need to pass the props it needs here
      <MyComplexTable serverComponent={<MyTable id={queryParams.id}/>} />
    </>
  )
}

'use client';
export const MyComplexTable = (serverComponent: JSX.Element) => {
  const queryParams = useSearchParams();

  return (
    <>
      <ComponentThatNeedTheId />

      // Here I want to be able to pass the ID
      {serverComponent}
    </>
  )
}

[icyJoseph]

The roundtrip isn't what you're optimizing away. What differs between client and server fetch is what re-renders and who owns the cache, not whether a network call happens. So the choice is about ownership and invalidation, not latency-elimination.

A deep tree of cheap server components costs nothing to re-render. The cost is where you await. If you await searchParams or a fetch high up, the whole page render blocks on it. If you pass the un-awaited promise down and await it inside one small Suspense wrapped subtree, the shell flushes immediately, with fallback UI, the subtree data streams alter.

Isolate the await behind a Suspense boundary as low as possible. See, https://nextjs.org/docs/app/guides/streaming#push-dynamic-access-down.

There's a couple choices to make here:

<Suspense key={id} fallback={<Skeleton/>}>

Changing the key remounts the boundary. It's a fresh mount with no "already-revealed content". The the fallback shows on every id change. You get a skeleton flash each time. Good when each id is a genuinely different thing and a clear "loading the new thing" signal is what you want.

Wrap the navigation in a transition

React's rule: it will not hide already-revealed content with a fallback during a transition. So if the table is already on screen and the transition causes the server component to suspend, React keeps the old table visible and just flips isPending true. You dim the table / show a spinner via isPending, old data stays put until new data streams in.

Pick one:

• If you need to "show me a skeleton each time", then key it.
• If you want to "keep the table, while it is refreshing", then use isPending.

<Link> and router navigations are already transitions internally, so for soft-nav param changes you get this pending behavior for free. If you want an explicit pending flag you can either useTransition around a manual router.push, or use Next 16's useLinkStatus for <Link>-driven loading state.

Goal	Tool
Don't block the shell on the fetch	pass un-awaited promise down, await low
Stream the slow part in	<Suspense> around that subtree
Skeleton on every id change	<Suspense key={id}>
Keep old table, show "refreshing"	no key + isPending (useTransition / useLinkStatus)
Don't even re-render the static shell	Cache Components (cached shell + dynamic PPR hole)

All of these are still "server fetch + roundtrip", they're just about hiding the roundtrip well. Client fetch (SWR/React Query) remains the escape hatch when the data is browser-state/real-time/interaction-gated, at the cost of owning the cache.

---

And a side note, a Client Component can be parent (not rendering owner) of a Server component: https://nextjs.org/docs/app/getting-started/server-and-client-components#interleaving-server-and-client-components

As said before, there'll likely be an API to do what you are thinking about, in the short/medium term future, but for now, the above applies.