Next.js Data Fetching
Last updated: 2026-11-02
Next.js Data Fetching Next.js Data Fetching
In a Next.js server component you can await fetch directly, and next.revalidate controls the caching strategy: SSG, ISR and SSR are all expressed through the same API. Caching is the default behaviour, so understanding the strategies is what lets you balance speed against data freshness without giving up either one.
| Group | Ecosystem |
|---|---|
| Kind | Pattern |
| Since | Next.js 13.4+ (App Router stable); fetch is no longer cached by default since 15 |
ℹ️ Info The editor transpiles JSX to JavaScript and renders the real UI in a sandbox; components mount automatically — no manual render call needed.
📝 Syntax
// Fetch directly inside a server component (no useEffect needed)
const res = await fetch('https://api.example.com/posts', {
next: { revalidate: 60 } // ISR: cached for 60 seconds
})
const posts = await res.json()
// Other strategies:
// next: { revalidate: 0 } → SSR: fetched fresh on every request
// cache: 'no-store' → no caching at all (same as SSR)
// no options at all → SSG: fetched once at build time
// next: { tags: ['posts'] } → tagged, so revalidateTag can invalidate it precisely⚙️ Parameters
| next.revalidate | How many seconds the cache lives: 0 refetches on every request (SSR), leaving it unset fetches once at build time (SSG), and N regenerates the cache in the background every N seconds (ISR). |
|---|---|
| cache: 'no-store' | Disables caching entirely, which is equivalent to dynamic rendering and fits strongly real-time data. |
Returns：No return value — the data is fetched on the server; the strategies are described in the syntax and the example.
▶ Example
The example runs out of the box: it auto-renders when expanded, and edits take effect instantly.
Output：
Simulation: click the SSG / ISR / SSR buttons to switch strategies; the panel below shows the matching revalidate option, the data freshness (build-time snapshot, at most 60 seconds old, or live) and a short note on the use case, which makes the trade-off between speed and freshness easy to compare.💡 Key Points
⚠️ Warning Since Next.js 15 fetch is no longer cached by default: to get SSG or ISR you must write next.revalidate explicitly, so behaviour differs from version 14.
💡 Tip Tag your requests with fetch(url, { next: { tags: ['posts'] } }) and call revalidateTag('posts') after the data changes to invalidate exactly the right cache entries instead of regenerating the whole site.
ℹ️ Info Client components still fetch with useEffect or TanStack Query; server-side fetching logic must not live in a file marked 'use client'.
🏷️ More Ecosystem
💡 Related Cases
More case studies coming soon.
📚 Related Tutorials
❓ FAQ
Q How do I fetch data in a server component?
A Just await fetch(...) inside an async component — no useEffect and no state management. The request happens on the server at build time or request time, so nothing extra is shipped to the browser.
Q How do I choose between SSG, ISR and SSR?
A Use SSG for content that rarely changes (documentation, blog posts), ISR for data that needs regular updates (product pages, listings) and SSR for fully personalised or strictly real-time data. Different pages of one site can mix them freely.
Q Can a client component fetch this way?
A No. The next.revalidate option only takes effect on the server; in a client component use useEffect, SWR or TanStack Query and handle the loading and error states yourself.
