When a meta-framework app is exported to files only, which capabilities stop working and what replaces each?
answer
- ask: does it need request-time code
- before the response versus after
- each loss has a replacement cost
- client gates hide UI, not data
- content changes need another build
basics
~20 sEverything that needed code running per request goes: request-time rendering, server-handled writes, regeneration, interception before a route resolves, request-time media work. Each is replaced by a browser fetch, a separate service, host rules, or another build.
solid answer
~50 sThe rule is simple: if a capability needed your code to run while a request was open, it is gone. That removes HTML that varies by requester, server-handled form writes, regeneration of a prerendered page after a freshness window or on demand, interception before a route resolves (auth gates, redirects, header rewriting, experiment bucketing), request-time media processing, and any access to a secret. The replacements are not free. Per-request HTML becomes a generic document plus a browser `fetch` after load, which means the data is not in the delivered markup. Writes move to a separate origin with its own auth and CORS. Regeneration becomes a build per content change. Gates become either host-level redirect rules, where the host offers them, or client-side guards - and a client guard hides UI rather than withholding data, so the API must still enforce the rule.
go deeper
Learn the line rather than a list: work that had to happen while a request was open is gone. Name two concrete examples, such as per-user HTML and a form that posts to the app itself.
Be able to walk the matrix both ways - the capability that disappears and the substitute you would build - and to say out loud what each substitute costs the reader or the team.
Show that you have felt the replacements: the empty first paint, the extra origin and its auth, and a client guard that hides chrome while the API is the thing actually enforcing access.
Reason about the aggregate. Each substitution adds a dependency or a workflow, and the interesting question is whether the sum is still simpler than running one small server.
## The one rule the matrix follows Every capability a meta-framework offers sits on one side of a line: either it is work done **before the response is written**, or it is work done **in the browser afterwards**. A files-only export deletes the first side entirely, because there is no longer any of your code between the URL and the bytes. You do not need to memorise a list - you can derive it by asking of each feature: *does this need my code to run while a request is open?* ## The matrix, and what replaces each row | Capability lost | Why it goes | Usual replacement | What the replacement costs | |---|---|---|---| | HTML that varies by requester | nothing runs at request time | generic document + browser fetch after load | the data is absent from the delivered markup | | Server-handled form writes | no handler to receive the post | a separate API service, or a hosted form endpoint | another origin, its own auth, CORS | | Regeneration after a window or on demand | no process to re-render | a build per content change | an edit is live only after a build runs | | Interception before a route resolves | no request-time hook | host redirect/rewrite rules, or a client-side guard | rules vary by host; a client guard cannot withhold data | | Request-time media processing | no request-time compute | variants generated at build, or a media service | more build output, or a dependency | | Anything using a secret | the artifact is fully downloadable | move the call behind a service | an extra hop and a service to run | | Routes whose parameters are unknown at build | the document was never emitted | a client-rendered route that reads the parameter after load | the first paint has no content for that item | ## The replacement that hurts most: fetching after load Swapping request-time rendering for a browser fetch is the substitution teams reach for first, and the one they underestimate. Three consequences follow: 1. **The markup no longer contains the content.** Anything that reads the document without running scripts - link previews, some crawlers, a reader that fails to load the bundle - sees the empty state. 2. **A request chain appears.** The document must arrive, the bundle must download and execute, and only then does the data request start. The user watches a placeholder for the sum of those steps rather than reading content that was already in the HTML. 3. **Failure moves into the page.** A request that fails on a server produced an error response; the same failure now produces a loaded page with a broken region, and it needs its own handling. ## The replacement that fools people: a client-side gate A guard implemented in the shipped bundle runs **after** the host has already delivered the document and the bundle. It can redirect and it can hide UI, but at the moment it runs, everything in the artifact is already in the reader's hands. So: - a protected **route** can be hidden, but protected **data** must never have been prerendered into the artifact in the first place; - the API the page calls must enforce the rule itself, because the caller is under the reader's control; - expect a brief flash of protected chrome before the guard resolves, unless the shell is designed to render nothing until it has. This is not an argument against client-side gates. It is an argument that a client-side gate is a routing convenience, not an authorisation boundary. ## Where hosts blur the line Meta-frameworks differ in what they will even let you export, and hosts differ in what they add back. Some file hosts offer declarative redirect, rewrite and header rules, and some offer a small request-time layer - which can restore redirect-shaped interception and header control without restoring your application code. Treat those as *host* capabilities you are now coupled to, and write down which ones the deployment depends on, because they do not travel with the artifact if you move. ## Deriving it in an interview A strong answer does not recite a list. It states the line ("anything that needed my code while the request was open"), walks two or three concrete losses, and - crucially - names the **replacement and its cost** for each. The weak answer stops at "you lose server-side rendering", which is both imprecise (the rendering happened, just earlier) and incomplete (writes, gates, regeneration and secrets are the ones that actually derail a project).
- Which loss most often surprises a team after the export is already shipped?Interception before a route resolves. Redirects, auth gates, header rewriting and experiment bucketing all looked like small features, and each one now needs either a host rule or a client-side workaround with different semantics. Teams plan for rendering and forget the request-time middle layer.
- If a page's data is fetched in the browser anyway, does exporting lose anything for that page?Very little. A route whose content is per-user and fetched after load was already shipping a shell; exporting that shell changes almost nothing about what the reader receives. Those routes are the ones that port cleanly, which is why app shells and files-only hosting pair well.
- How do you handle a route whose parameters are only known after the build?Serve a client-rendered route that reads the parameter from the URL after load and fetches the record. Two things need attention: the host must route the unmatched path to that document, and an unknown record should still be presented honestly rather than as an empty page that claims success.
saying these in an interview costs you the question
- Claiming client-side fetching replaces request-time rendering at no cost
- Treating a client-side redirect as an authorisation boundary
- Thinking regeneration still runs, just on a shorter window
- Assuming form submissions still work because the framework handles them
- Believing environment variables keep secrets out of the exported bundle
- Saying only server-side rendering is lost, forgetting writes and gates