Confession: I was going to write this post back in November, then I opened the dashboard I’d just migrated to Server Components and noticed a waterfall I’d accidentally re-introduced. So I closed the draft, fixed the bug, and told myself I’d come back to it once I actually understood what I’d shipped. That was eight months ago. I think I understand it now. Probably.<\/p>\n
If you’ve been putting off touching Server Components because the marketing copy made it sound like a paradigm shift, the actually useful framing is much smaller: a Server Component is a function that runs on your server, returns JSX, and its source code never reaches the browser. That’s it. The rest is just figuring out where to draw the boundary between server and client, which is where most of the interesting bugs live.<\/p>\n
I’ve been running an App Router Next.js app in production for about eight months now. Here’s what stuck, what I got wrong, and what I still reach for client components for.<\/p>\n
The thing the docs say but I had to learn the hard way: Here’s the version of this I shipped on day one, which I’m not proud of:<\/p>\n I’d slapped The fix is to push the boundary down as far as possible:<\/p>\n Now the data fetch happens server-side during render, the chart’s interactivity stays client-side, and only the chart and its deps ship to the browser. The page itself is HTML by the time it hits the user. The React docs on Server Components<\/a> put this plainly once you read past the intro paragraphs, but I had to ship the bad version first to understand why.<\/p>\n Most of my pages now look like this: server component on the outside, client component island for the interactive bit, props passed across the boundary. The mental model that finally clicked: server components compose like normal React, but anything passed across the boundary has to be serializable. Functions don’t cross. Class instances don’t cross. Dates cross but you might be surprised by what they look like on the other side.<\/p>\n The server does the database work, hands the client the data it needs, and the client handles the parts that have to feel responsive. It’s not novel as an idea. I was doing roughly this with The wins I didn’t expect when I started:<\/p>\n Database calls in components stopped feeling weird.<\/strong> When you can The bundle dropped by about 35%.<\/strong> Most of it was libraries that no client component actually needed: the markdown renderer, the syntax highlighter, the schema validation library. They all moved server-side without me changing the code, just by virtue of being imported from server components. The first time I ran the build report after the migration I thought it was broken.<\/p>\n Auth checks stopped being a useEffect dance.<\/strong> I now check the session at the top of the server component, and either render the page or redirect. No flash of unauthorized content, no client-side loading state for “are you logged in.” Just synchronous code that runs before any HTML goes out.<\/p>\n Streaming made our slowest pages feel fast.<\/strong> The reports page has one query that takes about 800ms because we’re aggregating across a couple million rows. With If anyone tells you Server Components are simple, ask them about these:<\/p>\n 1. Accidentally importing a server-only module into a client component.<\/strong> The error messages have improved a lot, but I still hit this when I refactor. The trick I use now: any module with a 2. Forgetting that Server Components don’t re-render on the client.<\/strong> When a server component runs, it runs once per request. If you need values that change based on client state, you have to lift that state up into a client component, or use 3. The serialization edge cases.<\/strong> I had a bug where a Server Components aren’t the answer to everything. Things that still go client-side, no apologies:<\/p>\n\"use client\"<\/code> doesn’t just mark a component as client-side. It marks the boundary<\/em>. Everything imported from that file, and everything rendered as a child of those components, gets bundled and shipped to the browser.<\/p>\n\/\/ app\/dashboard\/page.jsx\n"use client";\n\nimport { useQuery } from "@tanstack\/react-query";\nimport DashboardChart from ".\/DashboardChart";\n\nexport default function DashboardPage() {\n const { data } = useQuery({ queryKey: ["metrics"], queryFn: fetchMetrics });\n return <DashboardChart data={data} \/>;\n}\n<\/code><\/pre>\n\"use client\"<\/code> at the top of the page because I needed a hook somewhere down in the tree. That single directive turned the entire page into a client bundle. Same fetch waterfall I had in the old Pages Router app, same bundle size, none of the streaming. I’d “migrated” to RSC and gotten zero of the benefits.<\/p>\n\/\/ app\/dashboard\/page.jsx (server component, no directive)\nimport DashboardChart from ".\/DashboardChart"; \/\/ can be a client component\n\nexport default async function DashboardPage() {\n const metrics = await getMetrics(); \/\/ runs on the server\n return <DashboardChart data={metrics} \/>;\n}\n<\/code><\/pre>\nThe pattern I use 90% of the time<\/h2>\n
\/\/ Server component\nexport default async function ProjectPage({ params }) {\n const project = await db.project.findUnique({ where: { id: params.id } });\n const tasks = await db.task.findMany({ where: { projectId: params.id } });\n\n return (\n <main>\n <h1>{project.name}<\/h1>\n <TaskList initialTasks={tasks} projectId={project.id} \/>\n <\/main>\n );\n}\n\n\/\/ app\/projects\/[id]\/TaskList.jsx\n"use client";\n\nimport { useState, useOptimistic } from "react";\n\nexport default function TaskList({ initialTasks, projectId }) {\n const [tasks, setTasks] = useState(initialTasks);\n \/\/ ...interactive logic\n}\n<\/code><\/pre>\ngetServerSideProps<\/code> for years. The difference is that I no longer have to write a separate API route to refetch after a mutation, and the streaming means the shell renders before the slow part finishes.<\/p>\nWhere Server Components quietly saved me<\/h2>\n
await<\/code> a Prisma query directly in a component, the temptation to invent a “data layer” abstraction goes away. I deleted three custom hooks (useProject<\/code>, useTasks<\/code>, useTeamMembers<\/code>) the week I migrated, because they existed only to wrap a fetch<\/code> to my own API. The data fetching now lives next to the thing that needs the data.<\/p>\n<Suspense><\/code> boundaries I can ship the header and the navigation immediately, then stream the slow chart in when it’s ready. I wrote more about Suspense patterns in 2026<\/a>, which is the same principle composing a little differently in the new model.<\/p>\nThe three things that still bite me<\/h2>\n
db.<\/code> call or a process.env.SECRET_*<\/code> reference gets a import \"server-only\"<\/code> line at the top, which forces a build error if anything tries to drag it client-side. Costs nothing, catches the bug at compile time.<\/p>\nrevalidatePath<\/code> \/ revalidateTag<\/code> to trigger a server-side refresh. I lost an afternoon trying to figure out why a filter dropdown wasn’t updating the list below it. The list was a server component. It was never going to update without a navigation.<\/p>\nDecimal<\/code> from Prisma was being passed as a prop to a client component, and on the client it became a plain string. The math broke silently. The Next.js docs on serialization<\/a> cover this, but you have to know to look. My rule now: at the server\/client boundary, convert anything weird to a primitive. Numbers, strings, booleans, dates, plain objects of those. Anything else, I assume the boundary will mangle.<\/p>\nWhen I reach for a client component instead<\/h2>\n
\n
useState<\/code> or useEffect<\/code>.<\/strong> Obvious, but worth saying.<\/li>\nlocalStorage<\/code>, IntersectionObserver<\/code>, window<\/code>, document<\/code>. The server doesn’t have these and pretending otherwise gets ugly.<\/li>\n