In a middleware chain, how does the order in which hooks are registered decide the order they run in?

## What registration actually does A server-side web framework does not decide per request which cross-cutting hooks to run. At startup you **register** them — the framework collects them into an ordered list and composes that list into one nested callable before the first request arrives. Registration is a build step: you are describing a shape, not issuing commands that execute where they are written. The composition rule almost every framework uses is **wrapping**. The first entry becomes the outermost layer; the second sits inside it; the third inside that; and the matched route handler sits innermost. A request enters from the outside and travels inward one layer at a time, because each layer decides for itself when — and whether — to hand control to the layer beneath it. ## Registration order is inbound execution order | Registered | Position in the chain | Before-phase runs | Hands control to | |---|---|---|---| | first | outermost | first | the second hook | | second | one layer in | second | the third hook | | last | innermost hook | just before the handler | the route handler | | the handler itself | innermost | last | nothing; it produces the response | Two consequences follow directly from that table: - **Anything a hook depends on must have been produced by a hook registered before it.** A hook cannot read a value that a hook further inside will attach later, because that one has not run yet. - **The handler is terminal.** It does not delegate onward, so there is no way to append work *after* it in the same list. Work that must happen around the handler is registered as a hook, which places it **outside** the handler rather than after it. ## Why the first-registered hook is the powerful one Being outermost means seeing every request that reaches the pipeline at all, including ones that a hook further in will reject or answer on its own. It also means running its after-phase **last**, when every inner layer has finished with the response. A hook that must genuinely wrap everything — measuring total time on the server, transforming the outgoing body, catching what escapes from inside — only gets that guarantee by being registered early. A hook registered late sees a narrower slice of traffic and a less finished response. The reverse is also worth stating plainly: a hook registered late cannot protect anything registered before it. If a guard sits deep in the chain, everything outside it has already run by the time the guard gets a say. That is why ordering is discussed as a correctness property and not a style preference. ## Where registration order is not the whole story Most frameworks offer at least one way to influence order other than the raw sequence of registration calls: - **Explicit order or priority values.** Each hook declares a number or rank, and the framework sorts by it. Positional order then only breaks ties. - **Named phases or stages.** Hooks are assigned to a stage; stages run in a fixed sequence, and position only matters within a stage. - **Attachment scope.** Hooks attached broadly and hooks attached to a narrower slice of routes interleave according to the framework's own rule — a separate axis from registration sequence, and one worth reading the manual for. - **Registration from several startup modules.** When more than one place adds hooks, the effective sequence depends on the order those places are visited, which is easy to change by accident. Because of these, the honest statement is: *the default is registration order, and the framework may layer explicit ordering on top of it.* A candidate who asserts that one universal rule applies everywhere is overreaching. ## Turning it into a habit 1. Write down the entry-order constraints first — which hook must be entered before which, and why. Constraints, not a fixed list, are what survives new hooks being added. 2. Register in one place, in that order, so the sequence is readable without tracing several startup modules. 3. Confirm instead of assuming: many frameworks can print the composed chain at startup, and an assertion over the composed order turns a silent reshuffle into a failing build. ## What interviewers listen for The answer they want is mechanical and short: the chain is built by wrapping, registration order is the order the before-phases run, and the handler is the innermost element that ends the chain. Candidates who have only ever pasted hooks into a startup file in whatever order tend to describe the list as a set rather than a sequence — which is exactly the misunderstanding that produces a guard sitting behind the work it was meant to guard.