What does `connection()` from `next/server` do when awaited in a Next.js App Router server component, and what does it solve that a fetch cache option cannot?

## The gap it fills Every other caching opt-out in Next attaches to a *data read*. You mark a `fetch` uncached, or you mark a cached function's entry short-lived. But a route can be wrong in a way that has nothing to do with data: ```tsx export default async function Page() { const nonce = Math.random() // evaluated whenever this renders const now = new Date().toISOString() // same return <p>{now} · {nonce}</p> } ``` If this route is prerendered, that render happens once, ahead of any user, and the timestamp and the random number are frozen into the output. There is no fetch here to mark `no-store` — the freshness problem is in the *execution*, not in the storage of a response. `connection()` exists for exactly this case. ```tsx import { connection } from 'next/server' export default async function Page() { await connection() const now = new Date().toISOString() return <p>{now}</p> } ``` ## What awaiting it means `connection()` returns a promise that is only meaningful once there is a real incoming request. During prerendering there is no request, so the render cannot proceed past the `await` — the work after it is excluded from the prerendered output and deferred to request time. That is the whole contract, and it explains two practical rules: 1. **Await it before the request-time code, not after.** Anything above the `await` may still be evaluated ahead of time. The boundary is positional. 2. **It marks the component it is in.** Put it in the small component that genuinely needs request time rather than in the page or, worse, a shared layout — the narrower the placement, the more of the route stays prerenderable. ## Versus the segment config `export const dynamic = 'force-dynamic'` answers the same need at a coarser grain: it declares the entire segment request-time. `connection()` is the component-scoped version of the same intent. Given a page where one badge shows a live timestamp and everything else is stable, the badge with an `await connection()` in it lets the rest of the page keep being prerendered, whereas the segment flag gives that up for the whole route. ## Versus `unstable_noStore` Before `connection()`, the same job was done by `unstable_noStore()` imported from `next/cache`: ```ts import { unstable_noStore as noStore } from 'next/cache' ``` It was always marked unstable, and Next 15 deprecated it in favour of `connection()`. You will still meet it in older codebases and in blog posts, and knowing that it is the predecessor — rather than a different feature — is a genuinely useful piece of interview trivia. When you migrate, the replacement is `await connection()`; note the `await`, since the old call was synchronous. ## The cost, and the honest caveat Everything below the `await` stops being prerenderable, so you pay a server render for that work on every request. Keeping the boundary low in the tree is what keeps that bill small. The caveat worth stating out loud in an interview: `connection()` is about your *own* render. It does not instruct a CDN or a browser about what to store. If a shared cache in front of the app is holding the response, per-request rendering on your side does not by itself make what the user sees fresh — that is a separate layer with its own controls. ## When you probably do not need it If the component already reads request-scoped input — the incoming cookies, headers, or search params — it is already tied to a real request, and adding `connection()` on top is noise. Reach for it specifically when nothing in the component *looks* request-dependent to Next but the output still must differ per request: clocks, randomness, generated identifiers, or a deliberate "never serve this from a prerender" marker in code that would otherwise seem perfectly static.