Sahan Singappulige

Introduction

Next.js has evolved beyond a traditional React rendering framework. With the App Router and React Server Components, developers can build applications that combine server-side data access with rich client-side interactivity.

One of the most important architectural decisions when building a Next.js application is determining which functionality belongs on the server and which belongs in the browser.

Making this decision correctly can improve performance, security, maintainability, and developer productivity.

1. Server Components vs. Client Components

In the Next.js App Router, pages and layouts are Server Components by default.

Server Components are particularly useful for:

• Fetching data from APIs and databases.
• Accessing server-side services securely.
• Rendering content without shipping unnecessary component JavaScript to the browser.
• Reducing client-side processing requirements.

Client Components become necessary when the interface requires browser-side interactions, React state, event handlers, or browser APIs.

The "use client" directive defines a client boundary.

2. Building a Server Component

Consider a product listing page that loads data from an external API.

// app/products/page.tsx

type Product = {
  id: number;
  title: string;
};

export default async function ProductsPage() {
  const response = await fetch(
    "https://dummyjson.com/products?limit=10"
  );

  if (!response.ok) {
    throw new Error("Failed to load products");
  }

  const data: { products: Product[] } =
    await response.json();

  return (
    <main>
      <h1>Products</h1>

      <ul>
        {data.products.map((product) => (
          <li key={product.id}>
            {product.title}
          </li>
        ))}
      </ul>
    </main>
  );
}

This page fetches and renders the product list on the server.

There is no need to introduce client-side state merely to display the retrieved data.

3. Introducing Client-Side Interactivity

Now consider a product search interface.

Search input state requires a Client Component:

"use client";

import { useState } from "react";

export default function ProductSearch() {
  const [query, setQuery] = useState("");

  return (
    <div>
      <input
        value={query}
        onChange={(event) =>
          setQuery(event.target.value)
        }
        placeholder="Search products..."
      />

      <p>Searching for: {query}</p>
    </div>
  );
}

The important architectural principle is to keep client boundaries focused.

A common mistake is marking an entire page or layout as a Client Component when only a small section needs interactivity.

Instead, Server Components can render Client Components as part of the component tree.

4. Understanding Rendering and Caching

Next.js provides several strategies for delivering application content.

Prerendering is useful when content can be prepared ahead of requests.

Dynamic rendering is appropriate when content depends on request-specific information.

Streaming allows portions of the interface to become available progressively rather than waiting for every operation to complete.

Caching is a separate decision. Developers should explicitly consider freshness requirements instead of assuming that every fetch behaves identically.

For example, public blog content and a personalized account dashboard have fundamentally different data freshness and privacy requirements.

5. Designing Clean Application Boundaries

In enterprise applications, Next.js should not become a place where all business logic is mixed directly into UI components.

A maintainable architecture might use:

app/
  dashboard/
  products/
components/
  ui/
  features/
lib/
  api/
  auth/
  validation/
services/
  products/
  customers/

This structure keeps presentation logic distinct from integration and domain concerns.

For more complex systems, Next.js can serve as a Backend-for-Frontend layer, communicating with dedicated backend services.

This is especially useful when multiple clients consume the same business APIs.

6. Security and Performance Considerations

Server-side rendering is not a replacement for authorization.

Every sensitive data operation should verify the requesting user's permissions.

Additionally:

• Avoid exposing credentials through client-side configuration.
• Keep client component boundaries as small as practical.
• Monitor data-fetching waterfalls.
• Use loading and error boundaries thoughtfully.
• Avoid unnecessary client-side dependencies.
• Measure real application performance rather than relying only on theoretical optimizations.

Conclusion

The real strength of Next.js comes from choosing the appropriate execution environment for each responsibility.

Server Components are excellent for data-centric rendering, while Client Components provide browser-side interactivity.

My key takeaway: Start with server-first rendering, introduce client-side behavior where needed, and keep business and infrastructure concerns separated from presentation logic.

This approach leads to applications that are easier to evolve as both user requirements and system complexity increase.