skip to content

When a visitor requests a dynamic path that the build never prerendered, what can a meta-framework do with that request?

level: middleimportance: should knowfreq 54%

answer

  1. outside the enumerated list
  2. three configurable behaviours
  3. not found, on demand, or a shell
  4. on demand needs a server and a guard
  5. a missing entity still deserves 404

basics

~20 s

Three behaviours are on offer: answer 404 because the path was not enumerated; render it on the server on first request and usually keep the output; or return a placeholder shell and fill it from the browser.

solid answer

~50 s

The enumerated list draws a line through the route's path space, and the framework has to be told what happens outside it. The strict option is to treat anything unenumerated as not found and answer `404`, which bounds the work a crawler or a crafted URL can force but hides every new entry until the next build. The permissive option renders the path on the server the first time it is asked for and normally keeps that output, so later visitors get a file; the path space opens up, at the price of a server and a guard against unbounded render cost. The third returns a placeholder shell immediately and lets the browser fetch the data — fast to first byte, but an empty page for anything that does not run scripts. Which options exist depends on the deployment: with no server, only the not-found answer and client-side fetching remain.

go deeper

for a junior

Know that prerendering only covers the paths the build was given, and that a request outside that set hits a configured fallback rather than magically working.

for a middle

Name the three behaviours and what each returns for the first request, and say which of them requires a server to be part of the deployment.

for a senior

Demonstrate the operational thinking: bound the work an unknown path can force, keep status codes honest, and avoid retaining a failed render as a page.

for a principal

Decide the policy per route family — closed sets get a strict not-found, growing catalogues get a bounded on-demand path — and make sure the cost of the open option is measured.

Prerendering a dynamic route means the build emitted files for the paths it was told about. The path space, though, is open: a link from elsewhere, a crawler, a newly published item, a typo, or a hand-crafted URL can all ask for a path that has no file. What happens then is a configuration decision, and the three answers have very different operational profiles. ## The three answers 1. **Not found.** The unenumerated path is treated as nonexistent: the response is `404` with the not-found page. The path space is exactly the enumerated list and nothing else. 2. **Render on demand.** The request is rendered on the server the first time it arrives, and in most implementations the output is kept, so subsequent requests for that same path are served like any other prerendered page. The path space is whatever the route's data loading can successfully answer for. 3. **Placeholder shell.** A prerendered shell — the layout, the chrome, a loading state — is returned immediately, and the page fetches the real data from the browser after it loads. The path space is open, but the first response contains no content. ## What each one costs | | Not found | Render on demand | Placeholder shell | |---|---|---|---| | Needs a server for this route | No | Yes | No | | New entries visible before a rebuild | No | Yes | Yes | | First response for an unknown path | `404` | Full HTML, after the render | Empty shell, immediately | | Cost a crafted URL can force | None | A render and its data fetches | A client fetch | | What a non-scripting client sees | The not-found page | The real content | The loading state | ## Choosing between them - **Closed sets choose not found.** If the enumeration is authoritative — every page that exists was enumerated — anything else is genuinely a bad URL, and answering `404` is both correct and the cheapest possible behaviour. - **Large or fast-moving sets choose render on demand.** When the catalogue grows between deploys, or when the tail is too long to prerender, rendering the tail on first request keeps the build bounded while the head stays prerendered. This is the common shape for a big catalogue: enumerate the valuable slice, let the rest arrive on demand. - **Shells suit content the user is signed in for, or content where the first paint matters more than the first bytes' completeness.** For anything that must be indexable or readable without scripts, a shell is the weakest of the three. ## The traps - **Unbounded work from crafted URLs.** Rendering on demand turns a URL into a work request. Without a check that the identifier actually resolves — and an early, cheap `404` when it does not — a loop over random paths becomes a load generator against your data source. Validate the parameter's shape before the expensive fetch. - **Keeping a failure.** If an on-demand render is retained, take care that an error page or an empty result is not the thing being kept for that path. Retaining a bad render is worse than re-rendering it. - **Status codes for missing data.** A route that renders on demand and finds nothing should still answer `404`, not a `200` with an "item not found" body. Anything that consumes status codes — crawlers, monitoring, caches — is misled by a successful status on a missing entity. - **Silent divergence.** A prerendered page and its on-demand counterpart come out of the same code, but not the same moment: one carries build-time data, the other carries fresh data. Two visitors comparing pages from the same route family can legitimately see different vintages. - **Assuming the option exists.** On a deployment with no server at all, options 1 and 3 are available and option 2 is not; the enumerated list becomes the whole site. ## The interview version of the answer Name the three behaviours, say which of them needs a server, and tie the choice to whether the path set is closed. A candidate who only knows "it 404s" has used one framework's default; a candidate who only knows "it renders it" has never thought about what a crafted URL costs.

  • Why is rendering unknown paths on demand a security and cost concern?
    Because each unknown path becomes a render plus its data fetches, and the path space is open. A loop over generated identifiers can push real load onto the origin and the data source. Validate the parameter cheaply and answer `404` before doing any expensive work.
  • If an on-demand render finds no such item, what status should the response carry?
    `404`. Returning `200` with a "not found" body makes the miss invisible to crawlers, caches and monitoring, and can get an empty page indexed as a real one. The rendered body can still be friendly; the status has to be honest.
  • Does the placeholder-shell option work for content that has to be indexed?
    Poorly. The first response carries no content, so anything that does not execute the page's script sees only the loading state. If the content must be readable without scripts, prerender it or render it on the server instead.

saying these in an interview costs you the question

  • Assumes every framework simply 404s unenumerated paths
  • Renders any requested path on demand with no validation or cost guard
  • Returns 200 with a not-found body for a missing entity
  • Keeps an errored on-demand render as the page for that path
  • Thinks a placeholder shell is equivalent to prerendered content for crawlers
  • Forgets that on-demand rendering needs a server in the deployment