## Data Fetching in the App Router If you learned data fetching in traditional [React](/courses/reactjs), your brain probably remembers something like this: ```jsx useEffect(() => { fetch("/api/posts") .then(res => res.json()) .then(data => setPosts(data)) }, []) ``` Then you also needed: ```js useState() ``` plus: ```text Loading state Error state Data state ``` just to display some posts. [Next.js App Router](/courses/nextjs) looks at that and says: > "What if the server just fetched the data before rendering the component?" 😎 That's one of the biggest advantages of **[Server Components](/courses/nextjs)**. You can fetch data directly inside an [async](/javascript/promises-asynchronous-javascript) component: ```jsx export default async function Page() { const data = await getData() return

{data.title}

} ``` No `useEffect`. No client-side loading dance. No unnecessary API request from the browser. --- # The Basic Data Fetching Flow With a Server Component, the flow can look like this: ```text User requests page ↓ Server Component runs ↓ Server fetches data ↓ React renders the result ↓ Next.js sends the UI to browser ``` Instead of: ```text Browser loads page ↓ JavaScript loads ↓ Component renders ↓ useEffect runs ↓ Browser requests data ↓ State updates ↓ Component renders again ``` That's a lot fewer trips around the block. 😄 --- # 1. Fetching Data with Async Server Components [Server Components](/courses/nextjs) can be: ```js async ``` which means you can directly use: ```js await ``` inside them. Example: ```jsx async function getPosts() { const response = await fetch( "https://jsonplaceholder.typicode.com/posts" ) if (!response.ok) { throw new Error( "Failed to fetch posts" ) } return response.json() } export default async function PostsPage() { const posts = await getPosts() return (

{post.title}

{post.body}

) } ``` Notice what's missing: ```js useEffect() ``` and: ```js useState() ``` The component simply waits for the data on the server and then renders it. --- ## Server Components Can Fetch More Than APIs You're not limited to: ```js fetch() ``` Server Components can fetch data from: - [REST APIs](/courses/expressjs) - GraphQL APIs - Databases - ORMs - File systems - CMS platforms - Backend SDKs For example, using a database: ```jsx import { db } from "@/lib/db" export default async function UsersPage() { const users = await db.user.findMany() return (

{user.name}

) } ``` No API endpoint required. Conceptually: ```text Server Component ↓ Database ``` instead of: ```text Server Component ↓ Your own API ↓ Database ``` If both pieces of code already run on your server, that extra HTTP trip often isn't necessary. --- # Fetch Data Where You Need It Another useful App Router pattern is fetching data close to the component that actually uses it. Instead of this: ```text Page ↓ Fetch everything ↓ Pass data ↓ Pass data again ↓ Pass data again ↓ Component finally uses it ``` you can often do: ```text Page ├── Profile → fetch profile ├── Posts → fetch posts └── Analytics → fetch analytics ``` Each Server Component can fetch the data it needs. This keeps components easier to understand and reduces unnecessary prop drilling. --- # What is a Data Fetching Waterfall? Here's an important performance concept. Imagine you write: ```js const user = await fetchUser() const posts = await fetchPosts() const comments = await fetchComments() ``` The second request waits for the first. The third waits for the second. Conceptually: ```text fetchUser() ↓ wait... ↓ fetchPosts() ↓ wait... ↓ fetchComments() ``` If each request takes one second: ```text 1s + 1s + 1s = ~3 seconds ``` This is called **sequential data fetching**. When requests unnecessarily wait for each other, you can create a: **Data Fetching Waterfall** > **Definition: Data Fetching Waterfall** > > A waterfall happens when one data request waits for another request to complete before starting, even when the requests could have run at the same time. Server Components make server-side fetching easier, but they do **not magically eliminate every waterfall**. You still need to structure independent requests properly. --- # 2. Parallel Data Fetching Suppose these requests do not depend on each other: ```text User Posts Comments ``` Then there's no reason to wait for them one by one. Instead of: ```js const user = await fetchUser() const posts = await fetchPosts() const comments = await fetchComments() ``` start them together: ```js const userPromise = fetchUser() const postsPromise = fetchPosts() const commentsPromise = fetchComments() const [ user, posts, comments ] = await Promise.all([ userPromise, postsPromise, commentsPromise ]) ``` Now the timeline looks more like: ```text fetchUser() ──────────┐ fetchPosts() ──────┐ │ fetchComments() ────────┐ │ ↓ ↓ ↓ Done ``` Instead of: ```text A + B + C ``` your total time is closer to: ```text slowest(A, B, C) ``` Much better. --- ## Simpler Parallel Example You can also write: ```js const [user, posts, comments] = await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ]) ``` Use this when the requests are independent. --- ## When Sequential Fetching Is Correct Not every waterfall is bad. Sometimes request B genuinely needs data from request A. For example: ```js const user = await getUser() const orders = await getOrders( user.id ) ``` You can't fetch orders before knowing: ```js user.id ``` So this dependency is valid: ```text Find user ↓ Get user ID ↓ Fetch user's orders ``` The goal isn't: > "Never use sequential requests." The goal is: > "Don't make independent requests wait for each other." --- # 3. Understanding Caching Now we enter one of the most misunderstood parts of [Next.js](/courses/nextjs). **Caching.** And yes, [Next.js](/courses/nextjs) caching has changed over time. So if an old tutorial tells you: ```text fetch() = cached forever by default ``` that's outdated for modern Next.js. A plain: ```js fetch(url) ``` is **not automatically data-cached by default** in current Next.js. Example: ```jsx const response = await fetch( "https://api.example.com/posts" ) ``` Treat this as fresh data unless you explicitly opt into caching behavior. --- # Why Cache Data? Imagine your blog homepage receives: ```text 100,000 visitors ``` and every visitor causes this query: ```text Database → Load same 20 blog posts ``` even though the posts haven't changed all day. That's a lot of unnecessary work. Caching lets you do something closer to: ```text First request ↓ Fetch data ↓ Store result ↓ Future requests ↓ Reuse cached result ``` This can improve: - Performance - Database load - API costs - Response times - Scalability --- # Modern Next.js 16 Caching: `use cache` Next.js 16 introduced the modern **Cache Components** model. When Cache Components are enabled, caching becomes explicit. First enable them: ```js // next.config.mjs const nextConfig = { cacheComponents: true, } export default nextConfig ``` Now you can cache a [function](/javascript/functions-in-javascript) using: ```js "use cache" ``` Example: ```js export async function getPosts() { "use cache" const response = await fetch( "https://api.example.com/posts" ) return response.json() } ``` The return value of this [function](/javascript/functions-in-javascript) can now be cached. Think: ```text Normal function ↓ Fresh work ``` versus: ```text "use cache" ↓ Reusable cached result ``` --- # Caching Database Queries One nice thing about: ```text "use cache" ``` is that it isn't limited to `fetch()`. You can cache database queries too. Example: ```js export async function getProducts() { "use cache" return db.product.findMany() } ``` Then: ```jsx export default async function ProductsPage() { const products = await getProducts() return (

{product.name}

) } ``` This is especially useful because databases don't have: ```js fetch(..., { cache: "force-cache" }) ``` The caching boundary is around the **function itself**. --- # 4. Controlling Cache Lifetime with `cacheLife()` Caching something forever probably isn't what you want. Blog posts change. Products change. Documentation changes. That means cached data eventually needs refreshing. Next.js provides: ```js cacheLife() ``` to describe how long cached content should remain valid. Example: ```js import { cacheLife } from "next/cache" export async function getPosts() { "use cache" cacheLife("hours") const response = await fetch( "https://api.example.com/posts" ) return response.json() } ``` Here we're telling Next.js: > "This data can be cached using the `hours` cache profile." --- ## Built-In Cache Profiles You'll commonly encounter profiles such as: ```text seconds minutes hours days weeks max ``` Example: ```js cacheLife("minutes") ``` for frequently changing content. Or: ```js cacheLife("days") ``` for content that changes less often. --- ## Custom Cache Lifetime You can also provide more control: ```js cacheLife({ stale: 3600, revalidate: 7200, expire: 86400, }) ``` These values are measured in seconds. Conceptually: ```text stale ↓ How long cached content can be considered fresh ``` ```text revalidate ↓ When Next.js should refresh it ``` ```text expire ↓ How long before the cache should no longer be used ``` For beginner projects, built-in profiles are usually easier: ```js cacheLife("hours") ``` Much less brain damage. 😄 --- # Time-Based Revalidation Suppose you have a blog. The posts change occasionally, but not every second. You could cache them: ```js import { cacheLife } from "next/cache" export async function getPosts() { "use cache" cacheLife("hours") return db.post.findMany() } ``` Now Next.js can reuse cached results while refreshing them according to the configured cache lifetime. This gives you a useful balance: ```text Fast cached responses + Fresh-enough data ``` --- # What is Revalidation? **Revalidation** means refreshing previously cached data. Conceptually: ```text Cached Data ↓ Becomes stale ↓ Fetch newer data ↓ Update cache ``` This allows you to get much of the speed of static/cached content without keeping old data forever. --- > **Interview Highlight** > > **Q: What is revalidation in Next.js?** > > Revalidation is the process of refreshing cached data so an application can continue serving fast cached responses while eventually updating them with newer data. --- # On-Demand Revalidation Time-based updates aren't always ideal. Imagine an admin publishes a new article. You don't want to say: > "Cool. It'll appear sometime in the next six hours." 💀 Instead, you can invalidate cached data when the update actually happens. Next.js provides APIs such as: ```js revalidatePath() ``` and: ```js revalidateTag() ``` --- # `revalidatePath()` Suppose you update a blog post. After the mutation: ```js import { revalidatePath } from "next/cache" export async function updatePost() { await db.post.update({ // ... }) revalidatePath("/blog") } ``` This tells Next.js that cached content associated with: ```text /blog ``` needs to be revalidated. --- # Cache Tags For more targeted invalidation, cached data can be associated with tags. Example: ```js import { cacheLife, cacheTag } from "next/cache" export async function getPosts() { "use cache" cacheLife("hours") cacheTag("posts") return db.post.findMany() } ``` Now you've labelled that cached data: ```text posts ``` Later you can revalidate it: ```js import { revalidateTag } from "next/cache" export async function createPost(data) { await db.post.create({ data }) revalidateTag("posts", "max") } ``` Conceptually: ```text Create new article ↓ Database updates ↓ Invalidate "posts" cache ↓ Fresh content becomes available ``` Much better than waiting for a timer. --- # Older Caching Syntax You'll Still See Because Next.js caching has evolved, you'll encounter plenty of existing applications using the previous caching model. You should recognize it. --- ## `cache: "force-cache"` Older/current non-Cache-Components projects can explicitly cache a `fetch()` request: ```js const response = await fetch( "https://api.example.com/posts", { cache: "force-cache" } ) ``` Think: ```text force-cache ↓ Reuse cached result ``` --- ## `cache: "no-store"` For always-fresh data: ```js const response = await fetch( "https://api.example.com/dashboard", { cache: "no-store" } ) ``` This tells Next.js not to store that fetch result in the data cache. Good for highly dynamic data such as: - Personalized dashboards - Live inventory - Account information - Frequently changing private data --- ## `next: { revalidate }` You'll also see: ```js const response = await fetch( "https://api.example.com/posts", { next: { revalidate: 60 } } ) ``` This means the cached data can be revalidated after approximately: ```text 60 seconds ``` This syntax remains important when reading existing Next.js projects. --- # Old vs Modern Caching Mental Model Older App Router projects commonly use: ```js fetch(url, { cache: "force-cache" }) ``` or: ```js fetch(url, { next: { revalidate: 60 } }) ``` Modern Next.js 16 applications using Cache Components increasingly use: ```js "use cache" ``` with: ```js cacheLife() ``` So think: ```text Previous model fetch options ↓ Control cache ``` versus: ```text Cache Components model "use cache" + cacheLife() ↓ Control cached functions/components ``` You'll see both in the wild. Understanding both means old tutorials won't jumpscare you. 😄 --- # Route Segment Configuration Older App Router code may also contain: ```js export const dynamic = "force-dynamic" ``` or: ```js export const revalidate = 3600 ``` Example: ```jsx export const dynamic = "force-dynamic" export default async function DashboardPage() { const users = await db.user.findMany() return (

{users.length} users

) } ``` You'll also see: ```js export const revalidate = 3600 ``` which sets route-level revalidation behavior. These options are still relevant in applications using the previous caching model. However, when **Cache Components** are enabled in Next.js 16, options such as: ```text dynamic revalidate fetchCache ``` are replaced by the newer caching model built around: ```text "use cache" cacheLife() Suspense ``` So learn the old syntax enough to understand existing projects, but build your mental model around the newer architecture. --- # 5. Loading UI with `loading.jsx` What happens if your data takes three seconds to load? Without a loading state: ```text User clicks ↓ ... ... ... ``` User: > "Hello? Website?" 👁️👄👁️ Next.js gives you a special file: ```text loading.jsx ``` Example structure: ```text src/app/posts/ ├── loading.jsx └── page.jsx ``` Then: ```jsx export default function Loading() { return (

Loading posts...

) } ``` Next.js can display this fallback while the route content is still loading. --- ## Skeleton Loader Example Instead of plain text: ```jsx export default function Loading() { return (

) } ``` Skeletons make loading feel much smoother. --- # `loading.jsx` and Suspense Behind the scenes, Next.js builds: ```text loading.jsx ``` on top of [React](/courses/reactjs): ```jsx ``` This enables **streaming**. Instead of waiting for every part of a route before showing anything, Next.js can progressively send UI as pieces become ready. Conceptually: ```text Page shell ↓ Sent immediately Posts ↓ Loading... Posts become ready ↓ Stream posts into page ``` We'll explore Suspense and streaming properly later. --- # 6. Handling Data Fetching Errors Suppose your API dies: ```js const response = await fetch(url) if (!response.ok) { throw new Error( "Failed to fetch posts" ) } ``` That error can be caught by the nearest: ```text error.jsx ``` boundary. Structure: ```text src/app/posts/ ├── error.jsx ├── loading.jsx └── page.jsx ``` --- ## `error.jsx` Example: ```jsx "use client" export default function Error({ error, reset }) { return (

Something went wrong!

{error.message}

) } ``` Important: ```text error.jsx ``` must be a **Client Component**. That's why it begins with: ```jsx "use client" ``` --- # What Does `reset()` Do? The error component receives: ```js reset ``` which lets you try rendering the failed route segment again. Example: ```jsx ``` So the experience becomes: ```text Request fails ↓ error.jsx appears ↓ User clicks Try Again ↓ Next.js attempts rendering again ``` Much nicer than: ```text Application crashed. Good luck. ``` 😅 --- # 7. Streaming Slow Components with Suspense Sometimes one slow request shouldn't block the entire page. Imagine a dashboard: ```text Header → fast Profile → fast Notifications → fast Analytics → very slow ``` You don't want: ```text Analytics is slow ↓ EVERYTHING waits ``` Instead, wrap the slow component in: ```jsx ``` Example: ```jsx import { Suspense } from "react" import Analytics from "./Analytics" export default function DashboardPage() { return (

Dashboard

Loading analytics...

} >

) } ``` Then: ```jsx export default async function Analytics() { const data = await getAnalytics() return (

{data.totalViews}

) } ``` Now Next.js can show: ```text Dashboard Profile Notifications Loading analytics... ``` and later stream in: ```text Analytics: 25,491 views ``` when it becomes ready. --- # Parallel Fetching vs Streaming These solve related but different problems. ### Parallel Fetching Use: ```js Promise.all() ``` when multiple requests can start together. ```text A ────────┐ B ─────┐ │ C ───────┐│ ↓↓ ``` --- ### Streaming Use: ```jsx ``` when parts of the UI should appear independently as their data becomes ready. ```text Fast UI ↓ Show immediately Slow UI ↓ Show fallback ↓ Stream later ``` You can use both techniques together. --- # 8. Client-Side Data Fetching Server-side fetching should usually be your starting point in the App Router. But sometimes data truly depends on browser interaction. Examples: - Autocomplete - Live search - Infinite scrolling - Browser-only APIs - Polling - Highly interactive dashboards - User-triggered requests That's when client-side fetching makes sense. --- ## Example: Search Suggestions Imagine the user types: ```text next ``` then: ```text nextj ``` then: ```text nextjs ``` You may want the browser to fetch new suggestions while they're typing. That interaction naturally belongs on the client. You could use: ```js useEffect() ``` but libraries such as: - SWR - TanStack Query provide convenient features including caching, refetching, deduplication, retries, and loading states. --- # Client Fetching with SWR Example: ```jsx "use client" import useSWR from "swr" const fetcher = url => fetch(url).then(response => response.json() ) export default function SearchResults({ query }) { const { data, error, isLoading } = useSWR( `/api/search?q=${query}`, fetcher ) if (isLoading) { return

Searching...

} if (error) { return

Search failed.

} return (

{item.title}

) } ``` Because this depends on interactive browser state: ```text User typing ↓ query changes ↓ Fetch results ``` client-side fetching makes sense. --- # Server Fetching vs Client Fetching Don't choose based on: > "Which one looks cooler?" Choose based on where the data is needed. ### Use Server Components when: - Data is needed to render the page - You're querying a database - You're using private credentials - SEO matters - The browser doesn't need to initiate the request - You want less client-side [JavaScript](/courses/javascript) ### Use Client Components when: - Data depends on browser state - Data changes because of user interaction - You're building live search - You're polling frequently - You're using browser APIs - A client-side data library is appropriate --- # A Real-World Example Imagine an e-commerce product page. You need: ```text Product Details Reviews Recommendations Add to Cart Live Stock Indicator ``` A sensible architecture might be: ```text Product Page │ ├── Product Details │ ↓ │ Server fetch │ ├── Reviews │ ↓ │ Cached server data │ ├── Recommendations │ ↓ │ Suspense + server fetch │ ├── Add To Cart │ ↓ │ Client interaction │ └── Live Stock ↓ Client fetching ``` You don't have to choose one fetching strategy for the whole application. Use the right strategy for each piece. --- # Quick Decision Guide Ask yourself: ```text Does this data belong to the initial page? ``` If yes: ```text Server Component ``` Then ask: ```text Can this data safely stay the same for a while? ``` If yes: ```text Cache it ``` If no: ```text Keep it fresh/dynamic ``` Then ask: ```text Are several independent requests waiting for each other? ``` If yes: ```text Promise.all() ``` Then ask: ```text Is one slow request blocking useful UI? ``` If yes: ```text Suspense / loading.jsx ``` Then ask: ```text Does fetching depend on browser interaction? ``` If yes: ```text Client-side fetching ``` That's basically your data-fetching decision tree. 🔥 --- # Quick Reference | Strategy | Modern Approach | Best For | |---|---|---| | **Fresh Server Data** | [Async](/javascript/promises-asynchronous-javascript) Server Component | Frequently changing data | | **Cached Data** | `"use cache"` | Reusable data that doesn't change constantly | | **Time-Based Cache** | `"use cache"` + `cacheLife()` | Blogs, docs, product catalogs | | **On-Demand Refresh** | `revalidateTag()` / `revalidatePath()` | CMS updates, mutations | | **Parallel Fetching** | `Promise.all()` | Independent requests | | **Streaming** | `` / `loading.jsx` | Slow parts of a page | | **Error Handling** | `error.jsx` | Failed route rendering/data requests | | **Client Fetching** | SWR / TanStack Query / browser fetching | Interactive browser-driven data | --- # Previous Caching Syntax Cheat Sheet You'll still see this in many Next.js projects: | Syntax | Meaning | |---|---| | `cache: "force-cache"` | Cache the fetch result | | `cache: "no-store"` | Always fetch fresh data | | `next: { revalidate: 60 }` | Cache and periodically revalidate | | `dynamic = "force-dynamic"` | Force route-level dynamic rendering | | `revalidate = 3600` | Route-level revalidation | Modern Next.js 16 with Cache Components increasingly prefers: ```text "use cache" cacheLife() cacheTag() revalidateTag() ``` So don't memorize one API and assume Next.js has never changed. It has. A lot. 😭 Understand the concept: ```text Fresh data Cached data Revalidated data Parallel data Streamed data Client-driven data ``` The syntax is much easier once those concepts make sense. --- ## Summary The App Router makes server-side data fetching a natural part of React components. Instead of automatically reaching for: ```js useEffect() ``` start by asking whether the data can be fetched directly in a Server Component. The most important ideas are: - Server Components can fetch data using `async/await` - Server Components can query databases directly - Plain `fetch()` is not data-cached by default in modern Next.js - Cache Components use `"use cache"` for explicit caching - `cacheLife()` controls cache lifetime - `cacheTag()` can label cached data - `revalidateTag()` and `revalidatePath()` refresh cached content - `Promise.all()` prevents unnecessary sequential waterfalls - `loading.jsx` provides route-level loading UI - `` allows more granular streaming - `error.jsx` handles route-level failures - Client-side fetching still makes sense for browser-driven interactions The big mental model is: ```text Need data? ↓ Fetch it on the server when possible ↓ Cache it when freshness allows ↓ Parallelize independent requests ↓ Stream slow sections ↓ Use client fetching only when the browser actually needs control ``` And that's how we'll keep approaching Next.js on **asif.to** — not as a giant collection of mysterious cache flags, but as a set of tools for one simple goal: get the right data to the user as quickly as possible without making the browser, server, or your future debugging self suffer unnecessarily. 🚀

{post.title}

Something went wrong!

Dashboard