Edge Middleware: V8 Isolate Execution & Cookie Header Rewrite
- Last updated
- Prerequisites:
- Next.js App Router and request lifecycle
- Understanding of HTTP headers and cookies
- nextjs
- middleware
- edge-runtime
- v8-isolate
- cookies
- proxy
Read at your depth
The practical view
Middleware in Next.js runs before a request reaches a route. export function middleware(request: NextRequest) { return NextResponse.redirect(new URL('/login', request.url)); }. Use it for auth checks, redirects, rewrites, and header/cookie manipulation. It runs on the Edge Runtime (or Node.js in Next.js 15.2+ with proxy.ts). Configure which paths run it via the matcher config: export const config = { matcher: ['/dashboard/:path*'] }. Middleware runs on every matching request — before the page, API routes, and static files (per matcher).
The same idea in other frameworks
Middleware is a server-side concern; React alone has no equivalent — it is framework-level (Next/Remix loaders).Angular Universal/NestJS guards approximate middleware on the server.Nuxt's route middleware + Nitro server routes play the same role.SvelteKit's hooks.server.ts handle() is the direct analogue.Legacy vs modern
Per-page auth checks vs a single middleware gate
Repeating auth checks in every page/route is error-prone; middleware centralizes the gate before any route code runs.
// ❌ OLD: repeated in every protected page
const session = await getSession();
if (!session) redirect('/login');export function middleware(req: NextRequest) {
const session = req.cookies.get('session'); // ✅ NEW: check once, before routes
if (!session) return NextResponse.redirect(new URL('/login', req.url));
}Interview gotchas
Context
This tests whether you understand the runtime model — interviewers want the V8-isolate constraint rationale, not just a list of forbidden APIs.
The mechanical answer
Edge middleware runs in a V8 isolate: a minimal, sandboxed runtime with Web-standard APIs only (Request/Response, fetch, URL, crypto, TextEncoder) and no Node.js globals (fs, process, Buffer is limited, require is unavailable). This exists because the Edge Runtime is designed to start in milliseconds on distributed edge nodes and run with a bounded CPU/memory budget; bundling Node APIs would make startup heavy and defeat the purpose. Code that needs Node APIs (reading files, using process.env beyond what's inlined) must either use the Node.js runtime (proxy.ts in Next.js 15.2+, which runs middleware in Node) or move that logic into route handlers/server actions. The constraint is a deliberate trade-off: speed and distribution vs full Node capability.
Trap
The naive answer is 'middleware is just a function that runs on the server'. On the Edge runtime it is a restricted sandbox, not full Node. Another trap: using process.env inside middleware expecting arbitrary env access — only inlined build-time env vars work; runtime secrets need the Node runtime or route handlers. Candidates who explain the V8-isolate sandbox and the proxy.ts alternative show real deployment knowledge.
Context
This probes the routing mechanics — redirect tells the browser a new URL, rewrite serves different content under the same URL — and the practical consequences for SEO, auth, and A/B testing.
The mechanical answer
A redirect (NextResponse.redirect) returns a 3xx status: the browser navigates to the new URL, which changes the address bar and is a full client-side navigation (for soft nav) or HTTP redirect (for hard nav). A rewrite (NextResponse.rewrite) internally serves content from a different route WITHOUT changing the URL — the browser keeps the original URL while the server renders the target. Use redirects for auth gates and moved content (canonical URL changes). Use rewrites for A/B testing (serve /variant-b at the /original URL), locale prefixes, and preserving URLs for SEO. Middleware rewrites are also used to map a request to a different route handler before the App Router renders.
Trap
The naive answer is 'they're basically the same'. Redirects change the URL (and can cause redirect loops if misconfigured); rewrites mask the URL (which can confuse analytics if not handled). Another trap: using a rewrite where a redirect is semantically required (e.g. after login) leaves the URL wrong. Candidates who map each to its use case (SEO, A/B, auth) show real understanding.