Terra.PKM — Write View

The fundamental problem with traditional React rendering is the network waterfall. When a component tree needs data from multiple sources, each level of nesting creates a sequential round-trip to the server. The parent fetches, renders, discovers it needs children, who then fetch, render, and so on.

This isn't a React problem — it's an architectural boundary problem. The real question is: where should the boundary between server and client actually live?

"Server Components don't just move rendering to the server — they eliminate the waterfall by co-locating data access with the components that need it, all within a single server pass."

With Server Components, the mental model shifts. Instead of thinking about "where does data live" vs "where does UI live," you think about what needs interactivity and what doesn't. Everything non-interactive stays on the server. Everything interactive becomes a Client Component.

The Three Patterns

In practice, I've observed three architectural patterns that emerge when teams adopt Server Components:

Parallel Fetching — Multiple server components at the same level fetch simultaneously. No waterfall. The server resolves all data needs in a single pass.

Streaming Boundaries — Suspense boundaries let you show partial UI while deeper components are still loading. Progressive rendering without client-side complexity.

Island Interactivity — Client components are islands within a server-rendered ocean. They hydrate independently and only ship the JavaScript they need.

The combination of these three patterns creates architectures that are both simpler to reason about and dramatically faster for users. The key insight is that composition replaces orchestration.

SERVER COMPONENT EXAMPLE

async function Dashboard() {
  // These run in parallel on the server
  const [metrics, activity, alerts] = await Promise.all([
    fetchMetrics(),
    fetchActivity(),
    fetchAlerts()
  ]);

  return (
    <div>
      <MetricsPanel data={metrics} />
      <Suspense fallback={<Skeleton />}>
        <ActivityFeed data={activity} />
      </Suspense>
      <AlertsClient initial={alerts} />
    </div>
  );
}

What I find most compelling is how this changes the conversation around performance. Instead of reaching for complex caching strategies or state management libraries, the default architecture is the optimization.

Server Components and the Waterfall Problem

The Three Patterns