Making Peace with Next.js App Router Caching

If you’ve moved to the Next.js App Router, you’ve probably hit the caching wall. You update a database row, refresh the page, and… nothing changes. The old data is staring right back at you.

For the first few weeks, I fought it. I sprinkled export const dynamic = 'force-dynamic' everywhere like salt just to make the pain stop. But that entirely defeats the purpose of the App Router's architecture.

Here’s what finally clicked for me:

The Mindset Shift

In the Pages router (getServerSideProps), the mental model was: fetch data on every request.

In the App Router, the default model is: build it once, serve the static result forever.

Next.js assumes your data hasn't changed unless you explicitly tell it otherwise. It’s not a bug; it’s an incredibly aggressive feature designed to make your site fast by default.

The Fix: On-Demand Revalidation

Instead of forcing everything to be dynamic (which kills performance), keep the aggressive cache and just pop the balloon when you actually update data.

Server Actions are the perfect place for this.

// actions.ts
'use server'
 
import { revalidatePath } from 'next/cache'
import { db } from '@/lib/db'
 
export async function updatePost(id: string, content: string) {
  // 1. Do the mutation
  await db.post.update({
    where: { id },
    data: { content }
  })
  
  // 2. Tell Next.js the cache for this route is stale
  revalidatePath(`/posts/${id}`)
  
  // If you want to blast the whole posts section:
  // revalidatePath('/posts', 'layout')
}

When this action runs, Next.js purges the cache for that specific path. The next person who visits (or the user who just submitted the form) gets a fresh server render. Everyone after that gets the new cached version.

The Takeaway

Stop fighting the cache. Let Next.js aggressively static-generate your pages, and use revalidatePath or revalidateTag right next to your database mutations. It takes a minute to get used to, but the performance benefits are massive.