Edge runtime vs Node.js runtime in NextJS - Visual Side-by-Side Comparison

Concept Flow - Edge runtime vs Node.js runtime

Request Received

↓

Check Runtime Type

↓

Edge Runtime

↓

Run Lightweight

↓

Fast, Limited

↓

Send Response

When a request comes in, Next.js decides to run it on Edge runtime or Node.js runtime. Edge runs fast with limited APIs, Node.js runs slower but supports full Node features.

Execution Sample

NextJS

export const runtime = 'edge';

export function GET(request) {
  return new Response('Hello from Edge!');
}

This code runs a simple API route on the Edge runtime, returning a fast response.

Execution Table

Step	Action	Runtime	APIs Available	Performance	Output
1	Request received	Check runtime	N/A	N/A	N/A
2	Determine runtime from export	Edge	Limited Web APIs	Very fast	Prepare response
3	Run handler function	Edge	Fetch, Request, Response	Very fast	'Hello from Edge!'
4	Send response	Edge	N/A	Very fast	Response sent to client
5	Request received	Check runtime	N/A	N/A	N/A
6	Determine runtime from export	Node.js	Full Node.js APIs	Slower	Prepare response
7	Run handler function	Node.js	File system, process, etc.	Slower	'Hello from Node.js!'
8	Send response	Node.js	N/A	Slower	Response sent to client
9	End	N/A	N/A	N/A	No more requests

💡 Execution stops after sending response to client.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 6	After Step 7	After Step 8	Final
runtime	undefined	'edge'	'edge'	'edge'	'nodejs'	'nodejs'	'nodejs'	undefined
response	undefined	undefined	'Hello from Edge!'	'Hello from Edge!'	undefined	'Hello from Node.js!'	'Hello from Node.js!'	undefined

Key Moments - 2 Insights

Why does the Edge runtime have limited APIs compared to Node.js?

Edge runtime runs in a lightweight environment close to the browser, so it only supports web-standard APIs like fetch and Response, unlike Node.js which supports full server APIs. See execution_table rows 2 and 6.

How does specifying 'export const runtime = "edge"' affect the code execution?

This export tells Next.js to run the code on the Edge runtime, enabling faster execution but limiting available APIs. This is shown in execution_table rows 2-4.

Visual Quiz - 3 Questions

Look at the execution table, what APIs are available at Step 3 when running on Edge runtime?

A Full Node.js APIs like file system

B No APIs available

C Limited Web APIs like fetch, Request, Response

D Only database APIs

💡 Hint

Check the 'APIs Available' column at Step 3 in the execution_table.

At which step does the Node.js runtime run the handler function?

A Step 7

B Step 4

C Step 3

D Step 2

💡 Hint

Look for 'Run handler function' with 'Node.js' runtime in the execution_table.

If you remove 'export const runtime = "edge"', which runtime will Next.js use by default?

A Edge runtime

B Node.js runtime

C Browser runtime

D No runtime

💡 Hint

Default runtime is Node.js if no runtime export is specified, see variable_tracker 'runtime' after Step 6.

Concept Snapshot

Next.js can run code on two runtimes:
- Edge runtime: fast, limited web APIs, runs close to user
- Node.js runtime: slower, full Node.js APIs
Specify runtime with 'export const runtime = "edge"'
Edge is great for fast responses; Node.js for full server features.

Full Transcript

This visual execution compares Edge runtime and Node.js runtime in Next.js. When a request comes in, Next.js checks the runtime type. If 'export const runtime = "edge"' is set, it runs on Edge runtime using limited web APIs like fetch and Response, resulting in very fast execution. Otherwise, it runs on Node.js runtime, which supports full Node.js APIs but is slower. The execution table shows steps for both runtimes handling requests and sending responses. Variables like 'runtime' and 'response' change accordingly. Key moments clarify why Edge runtime is limited and how specifying runtime affects execution. The quiz tests understanding of API availability, runtime steps, and default behavior. The snapshot summarizes the differences and usage of both runtimes.

Practice

1. What is the main advantage of using the Edge runtime in Next.js?

easy

A. It runs code closer to users for faster response times.

B. It supports all Node.js modules without restrictions.

C. It allows using server-side rendering only on the server.

D. It automatically caches all API responses indefinitely.

Solution

1. Step 1: Understand Edge runtime purpose

   The Edge runtime runs code on servers geographically closer to users, reducing latency.

2. Step 2: Compare with Node.js runtime

   Unlike Node.js runtime, Edge runtime focuses on speed by running near users but has some limitations on Node features.

3. Final Answer:

   It runs code closer to users for faster response times. -> Option A

4. Quick Check:

   Edge runtime = faster user response [OK]

Hint: Edge runtime means code runs near users for speed [OK]

Common Mistakes:

• Thinking Edge runtime supports all Node.js modules
• Confusing Edge runtime with full Node.js capabilities
• Assuming Edge runtime caches all responses automatically

2. Which is the correct way to set the runtime to Edge in a Next.js API route?

easy

A. export const runtime = 'nodejs';

B. const runtime = 'edge';

C. export default runtime = 'edge';

D. export const runtime = 'edge';

Solution

1. Step 1: Recall syntax for setting runtime

   Next.js requires exporting a constant named runtime with value 'edge' or 'nodejs'.

2. Step 2: Identify correct export statement

   The correct syntax is export const runtime = 'edge'; to set Edge runtime.

3. Final Answer:

   export const runtime = 'edge'; -> Option D

4. Quick Check:

   Use export const runtime = 'edge' [OK]

Hint: Use export const runtime = 'edge' to set Edge runtime [OK]

Common Mistakes:

• Using default export instead of named export
• Assigning runtime without export
• Setting runtime to 'nodejs' when Edge is needed

3. Given this Next.js API route code, what will be the runtime environment if export const runtime = 'edge'; is set?

export const runtime = 'edge';
export default function handler(req) {
  return new Response('Hello from Edge!');
}

medium

A. Node.js runtime with full Node APIs

B. Edge runtime with limited Node APIs

C. Client-side runtime in the browser

D. Serverless function with no runtime

Solution

1. Step 1: Check the runtime export

   The code explicitly sets runtime = 'edge', so it uses the Edge runtime environment.

2. Step 2: Understand Edge runtime features

   Edge runtime supports limited Node.js APIs and runs close to users for speed, unlike full Node.js runtime.

3. Final Answer:

   Edge runtime with limited Node APIs -> Option B

4. Quick Check:

   runtime = 'edge' means Edge runtime [OK]

Hint: runtime = 'edge' means limited Node APIs near users [OK]

Common Mistakes:

• Assuming full Node.js APIs are available in Edge runtime
• Confusing Edge runtime with client-side code
• Thinking no runtime is used

4. Identify the error in this Next.js API route code intended to run on Edge runtime:

export const runtime = 'edge';
import fs from 'fs';
export default function handler(req) {
  const data = fs.readFileSync('/data.txt', 'utf8');
  return new Response(data);
}

medium

A. Edge runtime does not support importing 'fs' module.

B. Missing async keyword for handler function.

C. Response constructor is used incorrectly.

D. The runtime should be set to 'nodejs' instead.

Solution

1. Step 1: Check module usage in Edge runtime

   Edge runtime does not support Node.js built-in modules like 'fs' because it runs in a restricted environment.

2. Step 2: Identify the error cause

   Importing and using 'fs' causes a runtime error in Edge runtime; this is not allowed.

3. Final Answer:

   Edge runtime does not support importing 'fs' module. -> Option A

4. Quick Check:

   Edge runtime forbids 'fs' module [OK]

Hint: Edge runtime forbids Node built-in modules like fs [OK]

Common Mistakes:

• Thinking async is required here
• Believing Response usage is wrong
• Assuming runtime setting is incorrect

5. You want to create a Next.js API route that uses crypto for hashing and runs as close to users as possible. Which runtime should you choose and why?

hard

A. Node.js runtime, because it supports all Node modules including crypto.

B. Node.js runtime, because Edge runtime does not support any crypto functions.

C. Edge runtime, because it supports Web Crypto API and runs near users.

D. Edge runtime, but you must polyfill crypto manually.

Solution

1. Step 1: Understand crypto support in runtimes

   Edge runtime supports the Web Crypto API natively, which can be used for hashing, while Node.js runtime supports Node's crypto module.

2. Step 2: Choose runtime for proximity and crypto

   Since you want to run close to users and use crypto, Edge runtime is best because it supports Web Crypto and runs near users.

3. Final Answer:

   Edge runtime, because it supports Web Crypto API and runs near users. -> Option C

4. Quick Check:

   Edge runtime + Web Crypto API = best choice [OK]

Hint: Edge runtime supports Web Crypto API and is faster globally [OK]

Common Mistakes:

• Assuming Edge runtime lacks any crypto support
• Choosing Node.js runtime despite wanting low latency
• Thinking manual polyfill is needed for crypto in Edge