📂 Pages Router vs. App Router: The Full Evolution 🚀

Next.js mein pages/ aur app/ directory ka confusion sabse bada hai. Ye sirf ek folder change nahi hai, balki Next.js ke kaam karne ke fundamental tarike mein ek bada shift hai.

🏗️ 1. Pages Router: The Classic Foundation

Pages Router ka simple rule tha: File-based Routing. Jo file pages/ folder mein hai, wahi URL ban jati hai.

Structure

• pages/index.js → /
• pages/about.js → /about
• pages/blog/[id].js → /blog/:id (Dynamic Routing)

Mental Model

React pehle client-side-first tha. Server ka role sirf data fetch karke props pass karne tak limited tha.

⚙️ 2. Data Fetching in Pages Router (The Old Ways)

Pages Router mein SSR aur SSG achieve karne ke liye special functions ka use hota tha.

🔹 getServerSideProps (SSR)

Har request par server par run hota tha. Fresh data ke liye best tha.

export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();
 
  return { props: { data } }; // Page component ko props ke through data milta tha
}

🔹 getStaticProps (SSG)

Build time par data fetch karke static HTML generate karta tha. Performance ke liye kamaal tha.

🔹 getStaticPaths

Dynamic routes ke liye batata tha ki kaunse IDs ya slugs ko build time par render karna hai.

❌ 3. The Problems (Why We Needed an Evolution?)

Dheere-dheere Pages Router mein kuch badi rukaawatein (bottlenecks) aane lagin:

Logic Fragmentation

UI logic component mein hota tha, lekin data fetching logic component ke bahar. Dono ke beech koi strong link nahi tha.

Mental Model Overload

Developer ko hamesha sochna padta tha:

"Kya main SSR use karu ya SSG? Kaunsa function export karu?" 🤔

No Partial Rendering

Pura page ek single unit ki tarah render hota tha. Agar ek chota component slow hai, toh pura page load hone mein wait karna padta tha.

Streaming impossible thi.

Large Client Bundle

Browser ko bahut zyada JavaScript download karni padti thi, chahe wo code server par hi run kyu na ho raha ho.

🚀 4. App Router: The Modern Powerhouse

App Router ka janam React Server Components (RSC) aur Suspense ko fully utilize karne ke liye hua.

✨ Key Features

Server‑First Architecture

Saare components default mein Server Components hote hain. Isse JS bundle size kaafi kam ho jata hai. 📉

Colocation

Data fetching ab directly components ke andar async/await se ho sakti hai.

Special File System

• layout.tsx → Shared UI (Navbar / Sidebar) jo re-render nahi hote
• loading.tsx → Instant loading states (Automatic Suspense)
• error.tsx → Targeted error handling

🧠 5. React Server Components (RSC) ka Role

RSC ne performance ki game badal di hai.

Zero Bundle Impact

Jo logic server par run ho raha hai, uski JS browser mein nahi jati.

Direct DB Access

Server components se aap directly database query kar sakte hain bina kisi extra API route ke. 🔒

Better Performance

Browser ko sirf final HTML aur thodi bahut interactivity milti hai.

🧩 The Chef & Waiter Analogy

Server Component → Chef 👨‍🍳

Saara heavy kaam (cutting, cooking) kitchen yani server mein hota hai.

User ko sirf final dish (HTML) milti hai.

Client Component → Waiter 🤵

Jo interactivity user ke saamne honi chahiye (button clicks, UI interaction), wahi browser mein chalti hai.

⚠️ 6. Common Migration Mistakes

Log aksar App Router ko purane tarike se chalane ki galti karte hain.

Overusing "use client"

Har file ke upar "use client" likh dena Server Components ka fayda khatam kar deta hai. 🚫

SSR Confusion

Har cheez ko dynamic banane ki koshish karna jisse server par load badh jata hai.

Copy‑Paste Migration

Bina logic samjhe purane getStaticProps ko naye architecture mein fit karna.

🎯 7. Final Summary: Which One to Use?

🧠 Conclusion

Migration ka matlab sirf code move karna nahi hai.

Real migration ka matlab hai Server‑First mindset adopt karna. 💡

🚀 Next Video Teaser

Next lesson mein hum App Router File System ko deep dive karenge:

• layout
• page
• template
• loading

Inka real internal power kya hai, wo next video mein dekhenge.