Server Components changed how I think about data

The old mental model

For years, the pattern was clear: components render UI, hooks fetch data, and state management glues them together. You'd mount a component, fire a useEffect, show a spinner, then render the data. The data fetching was always an afterthought bolted onto the rendering lifecycle.

The shift

With Server Components, data fetching moves to where it always should have been: the server. A component can directly await a database query or an API call. No hooks, no client-side state, no waterfall of requests. The component is the data layer.

This sounds simple but it rewires how you think about composition. Instead of lifting state up and drilling props down, you compose server components that each fetch exactly what they need. The parent doesn't need to know what data the child requires. Each component is self-contained.

What clicked for me

The moment it clicked was when I stopped thinking about "pages that fetch data" and started thinking about "components that know their data." A header component fetches the user session. A sidebar fetches navigation items. A dashboard widget fetches its own metrics. They compose together without a central data orchestration layer.

The tradeoffs are real

You lose the flexibility of client-side reactivity. You can't optimistically update a server component. The mental model of "this runs on the server, that runs on the client" adds a new dimension of complexity. The "use client" boundary becomes an architectural decision, not just a pragma.

Where I landed

Server Components aren't a replacement for client-side data fetching. They're a different tool for a different problem. The skill is knowing when your component needs server data at render time versus client interactivity after render. Once that distinction is clear, the architecture follows naturally.