Data Loading & Caching

Embedding the server's already-loaded result lets the browser's data cache start full, so the first client render reads it from cache instead of issuing a second request for data the user is already looking at.

A stored copy never learns that the data behind it changed. It becomes unusable only when the application names that copy and marks it stale, or when its freshness window elapses and the next request produces the value again.

A route's server-side data fetch runs when the URL matches, gathers the data that route needs, and hands it to the render, so the first HTML already carries the content and the browser needs no follow-up request.

A route-handled write is a server-side function the framework publishes at its own URL, so an ordinary HTML form can POST straight to it. The framework runs it on the server, then re-renders the route or follows a redirect.

The incoming request carries a session cookie; server-side code reads it from the request headers, resolves it to a session or user, and feeds that into the render. Identity is a per-request input, never module-level state.

You can only invalidate what you can name. Copies are addressed by the route path that produced them, by labels attached when the value was stored, or by nothing, leaving elapsed time as the only instrument.

Independently declared segment fetches can all start the moment the URL is matched, so they overlap. A waterfall appears when a child's fetch needs a value the parent's fetch produced, forcing it to wait for the parent to resolve first.

Exposing the function gives it a URL, and any client can send it any payload. Nothing the rendering page decided travels with the request, so identity, permission and input checks must live inside the handler.

Cookies ride on response headers, which are committed before the body streams, and a render may re-run or have its output reused. So sign-in, sign-out and session refresh belong in a write handler or a pre-routing step that owns the response.

Treat a wrong-account report as an exposure, not staleness: reproduce with two identities against a production-shaped build, then eliminate placements one at a time, using age or debug headers and a latency cliff as evidence.

A personalised value was read from a copy not keyed by identity, then frozen into a document free to be reused. Keep identity-dependent reads out of shared copies, and never let a document carrying a personal seed be shared.

Per-render dedupe collapses repeated reads within one request and is thrown away with that response, so it is private to the request. A store that outlives the request keeps the copy for later requests, which makes it shared.

A seeded entry is an ordinary cache entry: its worth depends on when the server actually read the value and on the freshness policy applied. Trust it while that window holds; revalidate when it lapses.

Fetch in the browser for data that is personal, live, or only needed after an interaction. It becomes a waterfall when a request can only start once its component renders, so a nested component's request waits on its parent's.

Segments whose match changed re-run; identically matched segments above them are commonly reused. The server runs the same code again but returns a serialised data payload for the changed segments, not a whole document.

A route's server-side fetch receives the whole request: matched path segments, query string, method, URL and headers. All of it is attacker-controlled, so validate every value before it reaches a query, a path, a redirect or an authorisation decision.

Return data when the user must stay in the form: field-level errors rendered back into the same route, with their input preserved. Redirect on success, so the result is a plain GET that can be reloaded and bookmarked without resubmitting.

A request-scoped memo: the first call performs the lookup, stores the in-flight result under the current request, and every later call in that render reuses it. The entry dies with the request, so nothing carries over to the next visitor.

Putting the user id in the key stops one user's entry reaching another, but only if every other input that varies the output is there too. It does not make the store private, and it trades hit rate for entry count.

The app never ran that write, so it needs an ingress: an endpoint the external system calls, naming what changed, which maps that onto labels or paths and purges. Authenticate it, validate it, keep a window.

Let the readers declare what they depended on, so one write purges by data name and reaches every consumer. Over-wide labels fail loudly as wasted work and origin load; under-wide labels fail silently as content nobody notices is stale.

The framework catches the throw and renders the nearest declared failure state in the matched chain, leaving the segments above it intact. How much of the page that replaces depends on where the nearest boundary sits.

Only a server-side rule makes it safe: a one-time token recorded as used, a uniqueness constraint, or an effect that assigns a value rather than a delta. Client-side guards reduce the odds, never the risk.

Because the write changed the store but nothing told the route's read steps they were out of date, so the response reused a result computed before the change. A write has to mark what it invalidated, not just redirect.

Capture the requested path and query, redirect to the sign-in route carrying it, and after a successful sign-in redirect there only if it is a local relative path; otherwise fall back to a default destination.

Default-deny: anything derived from who is asking stays request-bound or in the browser. Classify reads by audience, make placement visible at the call site, split pages so personal holes sit outside shared copies, and enforce it with a two-identity test.

Decide it on four axes: who the data belongs to, how fast it goes stale, how big it is, and whether the first screen needs it. Publish that as a default with a byte budget and a payload review.

Classify content by the cost of being stale, then per copy ask whether you can name it, whether the purge is acknowledged, and what the worst case is. Elsewhere the window is the promise.

Each site buys something different: a pre-routing step is uniform but coarse and cannot hand data to the route, a layout renders shared chrome, and a per-route read is explicit and precise. Most real apps use all three deliberately.