Frontend Beauty
ESC

Type to search the knowledge base.

Edge Runtime Tradeoffs

Edge Runtime vs Node.js in Next.js: cold starts, API limits, middleware, and when Node is the right default.

advanced3 min read
  • nextjs
  • edge-runtime

Next can run some code on the Edge Runtime (V8 isolates, Web APIs) instead of Node.js. Edge shines for low-latency middleware and tiny handlers near the user; Node wins for heavy libraries and full platform APIs.

Docs: Edge Runtime.

Declaring runtime

// route segment
export const runtime = 'edge'; // or 'nodejs' (default for many contexts)

Middleware is edge by nature.

Tradeoff table

Concern Edge Node
Cold start Often smaller Can be heavier
APIs Fetch, Request, limited crypto Full Node ecosystem
npm packages Many fail (fs, native addons) Broad support
DB drivers Prefer HTTP/driver edge-ready Traditional drivers OK
CPU-heavy work Poor fit Better

Good edge use cases

  • Auth cookie gate + redirect (middleware).
  • Geo/A-B rewrites.
  • Tiny personalization headers.
  • Lightweight JSON APIs with fetch to backends.

Bad edge use cases

  • Image processing with sharp.
  • Large ORMs assuming Node.
  • Long CPU-bound PDF generation.
  • Reading local files from disk.

Debugging tip

If a package “works locally” but fails on deploy, check whether the route is edge and whether the package uses Node builtins.

Interview out-loud

“Edge Runtime uses Web APIs with fast global starts but limited Node compatibility. I use it for middleware and small latency-sensitive handlers, and keep database-heavy or native-module work on Node. I set runtime explicitly when I need to be sure.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides