Where Next.js Middleware executes and Edge Runtime limits

What's really being asked

This question probes whether you understand the architectural boundary between the Edge Runtime and the Node.js runtime in Next.js. Middleware is not just another server function; it runs in a highly constrained, V8-isolate-like environment before the request ever reaches the application router or the Node.js server. Interviewers want to see that you know which APIs disappear, why package selection matters, and how this shapes what Middleware can realistically do.

A GOOD ANSWER COVERS four things in order. First, location: Middleware executes exclusively in the Edge Runtime, before route matching and before any page or API route logic in the Node.js runtime. Second, missing Node.js APIs: there is no filesystem access via fs or path, no Node.js crypto module, no Buffer, no process beyond process.env, and no CommonJS require. Third, dynamic code evaluation is blocked: eval, new Function, and WebAssembly.compile are disabled at runtime. Fourth, what remains available: standard Web APIs including fetch, Request, Response, Headers, Web Crypto, streams, timers, URLPattern, and the AsyncLocalStorage polyfill, plus environment variables via process.env. You should also mention that only ES modules are supported and that ISR is not available in the Edge Runtime.

COMMON WRONG ANSWERS include claiming Middleware runs on the standard Node.js server alongside pages, saying you can use fs to read a local config file, importing arbitrary npm packages that rely on native Node.js modules, or attempting to use eval for dynamic configuration. Another red flag is treating the Edge Runtime as simply a faster Node.js rather than a distinct Web-API subset. Candidates sometimes assume that because process.env works, all Node.js process methods are available, which is incorrect.

LIKELY FOLLOW-UPS include asking how you would share authentication logic between Middleware and a Node.js API route, which forces a discussion of using Web Crypto instead of Node.js crypto or jsonwebtoken. They might also ask how to work around a library that only runs in Node.js, where the correct path is to avoid it in Middleware or move that work to a Route Handler. A performance angle is also common: because Edge has faster cold starts, interviewers may ask when to prefer Edge over Node.js for Route Handlers.

ONE CONCRETE EXAMPLE is rewriting an auth check. A candidate might try to import the jsonwebtoken npm package inside middleware.ts to verify a JWT. This fails because jsonwebtoken depends on Node.js crypto and Buffer. The correct approach is to use the Web Crypto API directly or a lightweight library built for Edge runtimes, verifying the JWT via SubtleCrypto and returning NextResponse.rewrite or NextResponse.redirect based on the payload.