Learning Next.js - Core Concepts & Main Architecture

#Introduction

After understanding the history and position of Next.js in episode 1, it's time to open the hood. Episode 2 dissects the main architecture of Next.js: how requests flow, where pages are rendered, and what components make up a project.

With this understanding, you won't be confused when reading the documentation, seeing errors in the terminal, or telling the App Router and Pages Router apart. You'll also understand why the terms server runtime and Edge runtime exist — two execution environments with different strengths.

#Rendering Modes in Next.js

#SSR, SSG, ISR, and CSR

These four rendering modes determine when and where HTML is built:

• SSR: HTML is built per request on the server; always fresh, with a higher cost per request.
• SSG: HTML is built once during next build; very fast, but needs an update mechanism.
• ISR: SSG with periodic revalidation; pages are regenerated in the background when stale.
• CSR: JavaScript in the browser that builds most of the UI after the initial load.

In the App Router, the static or dynamic decision is often made automatically based on the APIs used — for example, using cookies() makes a route dynamic. Understanding these modes is the foundation for episodes 6 and 14.

#App Router vs Pages Router

#The Segment Concept and File Conventions

There are two routing paradigms in Next.js. The Pages Router (pages/) is the older paradigm that relies on files like pages/index.js and the getServerSideProps function. The App Router (app/) is the new paradigm based on React Server Components, shared layouts, and file conventions like page.tsx, layout.tsx, loading.tsx, and route.ts.

In the App Router, each folder is a segment that corresponds to a part of the URL. The file app/blog/[slug]/page.tsx represents a dynamic segment named slug. Segments can be nested, and each level can have its own layout.tsx. This is what lets a blog page layout have its own navbar without disturbing the dashboard page.

#Build Pipeline, Bundling, and Compilation

#The Build Process

When you run npm run build, Next.js performs several steps: compiles TypeScript and JSX into JavaScript, bundles all modules into fewer files, performs per-route code splitting, then prerenders static pages. The result is output ready for the server to run plus static assets ready for the CDN to cache. The build also runs type checking and linting, so errors are caught before production:

npm run build

The command npm run build produces a .next folder containing the optimized application. In projects using output: standalone, the build produces a .next/standalone directory that can be copied to your own server — we'll discuss that in episode 20.

You can think of the build as a factory: raw materials in the form of source code enter, pass through the compilation and bundling stations, and exit as finished products — static HTML, JavaScript split per route, and hashed assets. Each route produces its own chunk so the browser only loads the code the active page needs. This is code splitting working without manual configuration.

During the build, Next.js also performs static rendering: each static page is executed once and its HTML is written to disk. The result can be served straight from the CDN with no computation at request time — this is why static pages in Next.js feel so fast.

#Server Runtime vs Edge Runtime

The server runtime is the standard Node.js runtime: you can use all Node libraries, access the filesystem, and hold long-lived database connections. The Edge runtime is a lightweight Web Standard-based runtime that runs close to the user (CDN): very fast and memory-efficient, but limited to APIs available in the browser and unable to use pure Node libraries. Your runtime choice affects latency and capability — details covered in episode 21.

To choose the right runtime, consider three things: how long the logic runs, what libraries it needs, and how close users are to the server. Applications using an ORM and a database typically stay on the server runtime, while lightweight logic like redirects and authentication can move to the edge.

#Main Components and Workflows

#Project Structure

The structure of a modern Next.js project is relatively simple:

• app/: routing, layout, and page files.
• components/: shared React components.
• public/: static assets served directly.
• lib/ or utils/: helper code, configuration, and business logic.
• next.config.mjs: framework configuration.
• package.json: scripts and dependencies.

The public folder is the only place for assets served directly without processing. Files like favicons, logos, and static images go here and are accessed via the root URL. Meanwhile, files that need transformation — TypeScript, JSX, CSS — are handled by Next.js through the build pipeline and don't belong in public.

The app folder is the center of the application. The outermost layout usually defines the global page structure:

export const metadata = {
  title: "Aplikasi Next.js",
}
 
export default function RootLayout({ children }) {
  return (
    <html lang="id">
      <body>{children}</body>
    </html>
  )
}

The children above is the content of the active page. This root layout is mandatory in the App Router and is the foundation of all pages.

#Data Fetching, Streaming, Middleware, and Route Handlers

The core Next.js workflows revolve around four things: data fetching in a server component or on the client, streaming UI progressively via loading.tsx and Suspense, middleware for logic before the request reaches the page (authentication, redirects, i18n), and the route handler app/api/route.ts for building backend APIs. Each of these will be dissected one by one in episodes 6 through 13.

Also understand the order of execution: middleware runs first, then routing, then layouts and pages, and finally content is streamed to the client. This order helps you decide which layer a piece of logic belongs in.

Another note about the build: caching is also applied to compiled output, so the next build only works on the parts that changed. The effect is clearly visible during development — wait times drop drastically from the second iteration onward.

One file that's often overlooked is next-env.d.ts — a type declaration file generated automatically by Next.js that shouldn't be edited manually.

#Closing

Here's what to take away:

• The four rendering modes — SSR, SSG, ISR, CSR — can coexist.
• The App Router is based on segments and file conventions; the Pages Router is based on legacy files.
• The build pipeline performs compilation, bundling, code splitting, and prerendering.
• The server runtime is rich in Node APIs; the Edge runtime is lightweight and close to users.
• Main structure: app, components, public, lib, and next.config.mjs.
• Core workflows: data fetching, streaming, middleware, and route handlers.

In the next episode, episode 3, we'll get hands-on: starting a Next.js project with create-next-app, understanding the scaffolded folder structure, running the development server with hot reload, and setting up TypeScript, ESLint, and lint-staged. Get your terminal ready.