Server Components: The Boundary Everyone Gets Wrong

Q: What actually can and cannot be passed from a server component to a client component?

The rule is serialisability, because props crossing that boundary are serialised, sent over the network and deserialised in the browser — so anything that cannot survive that round trip cannot cross. Crosses reliably: strings, numbers, booleans, null and undefined; plain objects and arrays provided everything inside them is also serialisable; and JSX elements, which are already the payload format. Promises usually cross too, because frameworks stream them deliberately to enable progressive rendering. Does not cross: functions and closures, because there is no way to serialise executable code, with the deliberate exception of framework-designated server functions which are replaced by a reference the client can call; class instances, because the prototype chain and methods are lost, leaving a plain object that fails the moment you call a method on it; symbols; and anything holding a resource handle. The genuinely tricky middle is Date, Map, Set, BigInt and typed arrays — support is serialiser-specific, so verify against your framework rather than assuming, since an unsupported type frequently degrades silently into something wrong rather than throwing. The category with security rather than ergonomic consequences is server-only values: database clients, file handles, API credentials and environment secrets. These do not merely fail to cross usefully — if forced across as part of an object, their serialisable fields end up in the browser payload where anyone can read them. Frameworks provide server-only markers and taint APIs precisely because the default failure is silent. The practical discipline that avoids all of this: reshape to explicitly constructed plain data at the boundary rather than passing whatever your data layer returned.

Q: Why does marking a page with use client hurt bundle size so much?

Because the directive marks an entry point rather than a single file, and everything that file imports joins the client bundle transitively. When you put it at the top of a page to make one button work, you have not moved one component to the client — you have moved the page and its entire import graph. That includes the date library, the markdown renderer, the chart package and every utility those pull in, none of which needed to be in the browser. This is the single most common cause of disappointing bundle sizes in server-component applications, and it is easy to do accidentally because the immediate symptom of not doing it is an error message. A component uses useState, the framework errors, the fastest fix is adding the directive at the top of whatever file the error mentions, and the cost is invisible until someone measures the bundle weeks later. The correct approach is to push the boundary down to the smallest leaf that genuinely needs interactivity. A page with one dropdown should have one client component containing that dropdown, not a client page. Extract the interactive element into its own file, mark that file, and leave the page on the server. Two supporting techniques. Use the children slot: an interactive wrapper such as an accordion or tab panel can receive server-rendered content as children from a server parent, so the wrapper is client-side while its contents stay server-side and out of the bundle. And audit your boundaries periodically by looking at which files carry the directive and what they import, because boundaries drift downward in codebases as people fix errors rather than design placement.

Q: How is this different from a traditional API and BFF architecture?

It is the same architectural decision with the boundary moved from a network endpoint into your component tree, and recognising that makes both the benefits and the costs legible. In a traditional setup you have a backend exposing HTTP endpoints, possibly a backend-for-frontend shaping responses for the UI, and client code fetching, caching and managing loading states. The contract between them is explicit: a documented API with versioning, its own repository or module, and usually its own team. With server components, the component that renders data can query it directly. The data-fetching layer collapses into the render layer, and a whole category of code disappears — endpoint definitions, client fetch calls, loading state machinery, and often the client-side cache. That is a genuine simplification and it is the main reason to adopt this model. What you pay for it: the boundary still exists, but it is now implicit and distributed across every component rather than centralised in an API definition. Every developer working in the component tree is making serialisation decisions, whereas previously a smaller group owned the API contract. There is no versioning story because the server and client ship together, which is fine for a single application and unhelpful the moment a mobile client or third party needs the same data. And the discipline that API design taught — do not return raw database entities, shape responses deliberately, think about payload size — still applies, but nothing enforces it. The practical implication: if you also serve mobile apps or external consumers, you still need a real API. Server components replace the BFF for your web application specifically, not your data access layer generally.

Q: Should I still use a client-side data fetching library?

For server-rendered data, usually not — and keeping one is a common way teams get the complexity of both models with the benefits of neither. Server components fetch during render on the server, so there is no loading state to manage, no client cache to invalidate, no request waterfall in the browser and no effect-based fetching. Reproducing that machinery on top means maintaining a cache that duplicates what the server already resolved. You still want one for genuinely client-side data: anything fetched in response to user interaction after load, data that polls or streams, optimistic updates where the UI must reflect a change before the server confirms it, and infinite scroll or similar progressive loading driven by browser events. Those are real client concerns and a query library remains the right tool. The mixed pattern that works well: fetch initial data in a server component and pass it as props, then let a client library take over for subsequent interactions, seeded with that initial data so there is no redundant first request. Most query libraries support hydration from server-provided state for exactly this. Two migration cautions. Do not port a client-fetching architecture unchanged and then wonder why the benefits did not arrive — the loading skeletons, effect hooks and cache configuration frequently become dead weight. And verify that your framework request deduplication actually covers your data layer before relying on it: the guidance to fetch where data is used rather than lifting it to the top depends on deduplication working, and whether it does depends on how your queries are constructed.

Q: How do I avoid leaking secrets into the browser payload?

Treat it as a boundary security problem rather than a file-organisation one, because the failure is silent and development gives you no signal. A server component can read environment variables, hold database credentials and construct authenticated clients. If any value from that scope ends up as a prop on a client component — including nested inside an object you pass — its serialisable fields are in the payload downloaded by every visitor. Nothing crashes and nothing warns you. Four defences, roughly in order of reliability. Use your framework server-only marker on modules that must never reach the client; importing such a module from client code becomes a build error rather than a runtime surprise, which is the strongest guarantee available. Use taint APIs where your framework provides them to mark specific values as never-serialisable, which catches the case where the module is legitimately shared but a particular object is not. Reshape at the boundary by explicitly constructing the object you pass, listing the fields you intend rather than spreading an existing one — the spread operator is how most accidental leaks happen, because it carries fields you forgot existed. And follow the environment variable naming convention your framework uses to distinguish public from private, since the prefix is checked at build time. Two habits worth adopting. Review boundary props the way you would review an API response, asking what a user reading the payload would learn. And inspect the actual serialised payload in your browser network tab periodically on a page that handles sensitive data — it takes a minute and it is the only method that shows you what is genuinely being shipped rather than what you believe is being shipped.

Q: Do server components make sense for every application?

No, and the honest answer is that they earn their complexity in a fairly specific band. They fit well when you have server-side data density and rich client interaction in the same tree: dashboards backed by substantial queries, e-commerce with large catalogues and interactive filtering, content-heavy applications with personalised sections, and anything where you want server-rendered content without shipping the data layer to the browser. That combination is common enough to explain the adoption. They are overkill for a largely static site, where a static site generator produces better results with far less machinery, and for content-first pages with isolated interactivity, where hypermedia approaches solve the same problem more simply and with a smaller conceptual surface. They are a poor fit for applications that are essentially thick clients — design tools, editors, anything maintaining substantial in-browser state — because most of the work is client-side by nature and the boundary adds ceremony without removing anything. And they add little for an application that already has a mature API consumed by multiple clients, since the API is not going away and you now have two data paths. The decision worth making explicitly: what proportion of your pages are data-dense and server-rendered versus interaction-dense and client-driven? If most are the former with interactive islands, server components fit. If most are the latter, the boundary is friction rather than architecture. And the cost is real — every developer on the team now needs to understand serialisation, which is a genuine ongoing training and review burden rather than a one-time learning curve.

Q: How do the frameworks differ — React, Next.js, SvelteKit, Remix?

The vocabulary differs, the underlying constraint does not, and the meaningful axis is whether the boundary is implicit in the component tree or explicit in a separate loading layer. React server components are the reference implementation, with the use client directive marking client entry points and server functions providing the escape hatch for calling server code from the client. Next.js is where most teams encounter this, since its App Router builds directly on the React model and adds routing, caching and rendering conventions on top. SvelteKit takes the explicit approach: load functions run on the server and return data to the component, so the boundary is a named function with a clear input and output rather than a property of where a component happens to sit. Remix uses loaders and actions in a similar shape, with the data flow following the route hierarchy. The trade-off between the two styles is real and worth naming. Implicit boundaries in the component tree are more ergonomic — you fetch where you render, with no separate layer to maintain — and correspondingly easier to get wrong, because the boundary can move as a side effect of adding a directive. Explicit loaders are more verbose and harder to get wrong, since the serialisation point is a function signature you are looking at rather than an emergent property of the tree. Neither is correct in general. What transfers between them is the important part: in every one of these frameworks, data crossing from server to client is serialised, functions and class instances do not survive, secrets must not cross, and payload size is a cost paid by every visitor. Learn the constraint rather than the syntax and porting between frameworks is straightforward.

Q: What should I measure to know if my boundary placement is right?

Three numbers, and most teams currently track none of them. First, the serialised payload size per route — the data sent alongside HTML so the client can hydrate. This is invisible in your editor and downloaded by every visitor, and it is where the specific server-component regression lives. The classic case is a component rendering a large list server-side and passing the same rows to a client child, shipping the data twice: once as rendered HTML and once as serialised props. Check it in the network tab, then put a budget on it in CI so a regression fails the build rather than appearing in a lighthouse report months later. Second, client bundle size per route, which tells you whether your boundaries are placed where you think. A page that should be almost entirely server-rendered shipping a large bundle means a use client directive sits higher in the tree than intended, or a marked file imports something heavy. Track this per route rather than in aggregate, because the aggregate hides exactly the pages that regressed. Third, the count and location of client entry points. Enumerate the files carrying the directive and what each imports. This is a structural review rather than a metric, and it catches boundary drift — the tendency for directives to migrate upward over time as developers resolve errors by moving the boundary rather than by extracting a leaf. Two supporting practices. Review boundary changes as interface changes in code review, asking what crosses and why. And periodically inspect a real payload on a data-heavy route, since reading the actual bytes reliably surfaces both the duplication problem and any accidental over-sharing of fields.