A team wants Next.js middleware to load the signed-in user's full profile from the database on every request, so that pages do not have to fetch it themselves. Why is that the wrong surface, and where does the work belong?

## The instinct and why it is wrong "Middleware runs before everything, so let's do the common work there" sounds like a good deal. It is really two mistakes wearing one coat: a cost mistake and a data-flow mistake. ## Mistake one: you pay for it everywhere Middleware is the only Next.js surface that runs without the request naming it. Whatever its matcher selects goes through it — full page loads, client-side navigations, prefetch requests the router issues speculatively, and requests for other routes entirely. A database query there is not "once per page view"; it is once per matched request, and it sits in front of the work that actually produces a response, so its latency is additive for every one of them. The cost is also invisible in the places engineers look. A slow query in a component shows up next to the component. The same query in middleware shows up as "the whole site got slower", and it stays that way even for routes that never touch a profile — the marketing page, the health check, the asset-adjacent path someone forgot to exclude. ## Mistake two: there is no channel to the page Even if the cost were acceptable, middleware cannot give the page an object. It returns a response, not props. The only ways to pass what it learned downstream are the request/response envelope — setting a header or a cookie — or rewriting the URL so the path carries the value. Every one of those is a string. So the team's profile becomes a JSON string in a header, parsed back in a layout with no type safety at the seam, subject to header size limits, and duplicated into every downstream hop. If the profile changes mid-session, whatever went into a cookie is now stale until something rewrites it, and you have built a small, undocumented cache with no invalidation story. ## Where the work actually goes Fetch the profile where it is rendered. A Server Component — often a layout that wraps the authenticated area — can call the data layer directly. That gives you the type at the call site, colocation with the markup that consumes it, per-render deduplication when several components ask for the same thing, and access to the framework's caching and revalidation machinery when you want the result to persist beyond one render. If several branches of the tree need it, a small server-side accessor function that the framework can dedupe is the idiomatic shape. ```ts // app/(app)/layout.tsx import { getCurrentUser } from '@/lib/auth' export default async function AppLayout({ children }: { children: React.ReactNode }) { const user = await getCurrentUser() return <UserProvider value={user}>{children}</UserProvider> } ``` ## What middleware is genuinely for Keep it to decisions that must be made before a route is chosen and that need nothing more than the request envelope: - redirecting or rewriting based on the path, a cookie or a header; - attaching a locale, experiment bucket or correlation id; - setting response headers that apply broadly; - coarse gating of whole sections of the site. The test to apply: *does this decision have to happen before Next knows which route it is, and can it be made from the request alone?* If yes, middleware. If it needs the route's data, produces content, or only matters for one segment, it belongs downstream. ## The nuance worth voicing There is a defensible middle ground: a cheap check on data the request already carries — reading a session cookie's presence, decoding a token you can verify without I/O — to decide a redirect. That is a decision, not a data load, and it stays inside middleware's job. The line is between *deciding something about the request* and *fetching something the page needs*. Loading a full profile is unambiguously the second.