What must a bundle satisfy to run on an edge runtime target that a full server runtime does not demand?
answer
- a deliberately smaller runtime
- web-standard primitives only
- no filesystem, no native dependencies
- size and CPU budgets are hard
- failures show up as a module graph problem
basics
~20 sIt must use only the restricted API surface that runtime offers — web-standard request, response, streams and fetch — with no local filesystem or native dependencies, and stay inside tight bundle-size and per-request CPU budgets.
solid answer
~40 sAn edge runtime is deliberately smaller than a general server runtime. It typically exposes web-standard primitives — a request and response object, streams, `fetch`, text encoding, crypto — and little else: no local filesystem, no native binary dependencies, no arbitrary outbound sockets. Bundles are size-limited and each invocation gets a short CPU budget, because the point is many small instances near the user. So the adapter has to emit a *different* bundle for this target, and any dependency that reads files at runtime, compiles templates, encodes images or talks a database wire protocol over a raw socket will not run in it. Many targets offer both an edge runtime and a full one, so the practical answer is usually to keep the constrained code out of the edge bundle rather than to rewrite it.
go deeper
Recall that an edge runtime is a smaller environment with web-standard APIs only. No reading files from disk, no compiled native dependencies, and a limit on how large the bundle can be.
Explain why the adapter must emit a different bundle: a subset API surface plus size, CPU and memory budgets. Know that breakage is a module-graph problem — one transitive import can sink a bundle whose code path never runs.
Show how you would triage it: trace what pulled in the offending module, decide between keeping that work on the full runtime, swapping to an HTTP-based dependency, or moving it to build time. Gate bundle size in CI so growth fails early.
Judge how much of the platform you are willing to write against the narrow surface. Targeting it everywhere maximises placement freedom and constrains every library choice the org can make; confining it to a thin layer keeps the rest of the codebase ordinary.
An **edge runtime** is a small execution environment the host can start in many locations, close to users. It buys proximity by giving up generality, and everything an adapter must do differently for it follows from that trade. ## The API surface is a subset, not a superset A full server runtime exposes an operating system: files, processes, arbitrary network sockets, native extensions. An edge runtime typically exposes web-standard primitives only: - a **request** and **response** object, and streaming bodies - `fetch` for outbound HTTP - streams, text encoding/decoding, URL parsing, timers - a crypto interface for hashing and random values - environment values injected by the host What is usually absent matters more than what is present: - **No local filesystem at request time.** Anything that expected to read a template, a font file, or a data file from disk fails. Whatever the code needs must be inlined into the bundle at build time or fetched over HTTP. - **No native dependencies.** Libraries with compiled binary parts cannot load; image encoders and some parsers fall in this group. - **No arbitrary outbound connections.** A client that speaks a database wire protocol over a raw socket has nothing to open; talking to the same database over HTTP is the usual workaround. - **No long-lived process.** Each instance is short-lived, so in-memory state is even less durable than on a per-request function target. ## The budgets are real | Constraint | Typical shape | What it rules out | |---|---|---| | Bundle size | a hard ceiling per deployed unit | fat dependency trees, bundled data files, large polyfills | | CPU per request | a short budget, measured in milliseconds | template compilation, image or video work, big JSON transforms | | Memory | small compared with a server instance | holding large documents or datasets in memory while rendering | | Startup | must be near-instant | heavy module-level initialisation at import time | These are the reason an edge bundle is not simply "the server bundle, deployed elsewhere". The adapter must produce a build whose dependency graph is genuinely smaller, which is why some frameworks fail the build loudly when a module that cannot run in the restricted surface ends up in that graph — and why others only find out at the first request. ## What this means in practice The failure is usually at the **module graph** level, not the line level. One import of a helper that transitively pulls in a filesystem-reading module is enough to break the whole bundle, even if the code path that uses it never runs at the edge. Diagnosing it is a graph question: what pulled this in, and can that import be made conditional or moved? Three responses, in rough order of preference: 1. **Keep that work off the edge.** Many hosts can run more than one runtime for the same app, so the constrained code stays on the full runtime and only genuinely small work runs at the edge. This is usually the cheapest answer and needs no rewrite. 2. **Replace the dependency with an HTTP equivalent.** Data access over HTTP, an image service called with `fetch`, a prebuilt lookup table instead of a parser. 3. **Move the work to build time.** If a template compiles or a dataset can be inlined during the build, the edge bundle only has to read the result. ## A warning about silence As with other target mismatches, some of these degrade rather than error. A bundle that squeaks under the size limit today fails the next time a dependency grows. Work that fits the CPU budget for a small payload exceeds it for a large one, so the same route succeeds for most users and times out for a few. Both look like flakiness rather than a design mismatch, so it is worth asserting the limits in the build — check bundle size as a gate, and exercise the edge routes with realistic payload sizes rather than a smoke request. ## Where the boundary of this question sits Which runtime a given route *should* use is a placement decision with its own considerations: latency to the user versus latency to the data, and what state that route touches. This question is narrower and purely mechanical: **given that a route is going to the edge, what must the bundle look like, and what will refuse to run there.** Answer that first — placement reasoning is wasted on code that cannot execute in the target at all.
- Why does an unused import break an edge bundle?Because the constraint applies to the bundle, not to the executed path. If a module that needs the filesystem or a native binary is reachable in the import graph, it is bundled and evaluated on load, so the deploy or the first request fails even though no request ever calls it. The fix is to cut the import, not the call.
- How can a route reach a database from an edge runtime at all?Over HTTP. A client that opens a raw socket to speak the database's wire protocol has no socket to open, so the usual approaches are a data service that exposes HTTP endpoints, or a proxy running on a full runtime that the edge code calls with `fetch`.
- What should be gated in CI for edge-targeted routes?Bundle size against the host's ceiling, so a dependency bump fails the pipeline instead of the deploy, and a build that runs the real edge-target adapter rather than the development server. Add a request with a realistically large payload, since CPU-budget overruns only appear above a certain size.
saying these in an interview costs you the question
- Calls the edge runtime just a faster server runtime
- Assumes files can be read from disk at request time
- Expects native or compiled dependencies to load there
- Thinks an unused import is free in a size-limited bundle
- Treats a size or CPU limit as advisory rather than enforced