Should the per-request session read run before routing, in a layout, or in each route module, and how do you decide?

## Three places, three different jobs | Place | When it runs | Good at | Cannot do | |---|---|---|---| | Before routing | Every request matching its pattern, before a route is chosen | One uniform bounce; cheap coarse decisions; owning the response, so it may set cookies | Know which route matched or what it will show; hand its result to route modules as ordinary data in most frameworks | | In a layout | When that layout renders, which may be less often than every navigation | Rendering shared chrome that names the user | Pass data down to the route module beneath it in most file-based routers | | In the route module | Every time that route is produced | Precision: this route's own dependency, stated locally | Give you one place to change a rule across a hundred routes | The column that decides most arguments is the last one. Teams reach for a single read "at the top" expecting it to feed everything below, and discover that route modules are siblings in data terms, not children. ## Why a layout cannot be the single read A layout wraps a subtree visually and, in most routers, is fetched and rendered as a peer of the route rather than as its data provider. Two consequences: - The route module does not receive the layout's data, so it reads again — fine, because deduplication makes that one lookup, but it means the layout was never the single source. - Layouts often persist across navigations between their children, so a read placed there can be **staler** than the route below it. Anything security-relevant placed only in a layout can therefore be skipped entirely on a client-side navigation. Use a layout for chrome. Do not use it as the place a rule is enforced. ## Why the pre-routing step cannot be the single read either It has real strengths: it is uniform, it runs before any rendering work is spent, and it owns the response so it can redirect or set cookies. Its limits are just as real: - It frequently runs in a **constrained runtime** with a smaller API surface and stricter latency expectations, so a heavy session-store lookup there taxes every request including ones that never needed it. - It matches on URL shape, so its decisions are coarse; the interesting question is usually about the specific record a route is going to show. - Its result reaches the render only if you deliberately pass it — via a request-scoped value, or by attaching something to the request — which couples the two and is easy to get wrong. ## How I decide 1. **Correctness first.** The check that must not be bypassed goes next to the thing it protects: the route that renders the data, or the handler that performs the write. Anything earlier is defence in depth, not the control. 2. **Then uniformity.** If every route in a section needs the same bounce, put that bounce in the early step so a new route in the section is protected on the day it is added rather than the day someone remembers. 3. **Then cost.** Keep the early step cheap. If resolving a session is expensive, do the cheap structural check early and the authoritative one where it matters. 4. **Then ergonomics.** One exported helper for the read, imported everywhere, so deduplication works and an audit is a search rather than a reading exercise. 5. **Then blast radius.** Reading identity in a layout that wraps most of the app quietly makes a large surface request-dependent. Push the personal part down to the smallest subtree that genuinely needs it. ## The organisational angle On a large codebase, the property that matters is not which location is cleverest but which convention survives fifty contributors. A single documented helper and a rule that authoritative checks live with routes and writes is auditable: you can enumerate every surface that depends on identity, and a review can see the check in the same file as the data it guards. A scheme where protection is implied by directory position is fast to write and fails silently the first time someone adds a route in the wrong place or reorganises the tree. ## Failure modes to watch for - A rule enforced only before routing, bypassed by an internal navigation that never issues the request that step runs on. - A rule enforced only in a layout that persists across navigations and therefore does not re-evaluate. - Five private session helpers, so deduplication never fires and each page load makes five lookups. - The early step made authoritative and then made expensive, so every anonymous request pays for it.