Edge runtime vs Node.js runtime in NextJS - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Differences in API support between Edge and Node.js runtimes

Which of the following APIs is NOT supported in the Next.js Edge runtime but works in the Node.js runtime?

A The Node.js 'fs' module for file system operations

B The native Fetch API for HTTP requests

C Web Crypto API for cryptographic functions

D URL and URLSearchParams for URL parsing

💡 Hint

Think about which APIs require access to the server's file system.

The Edge runtime runs in a sandboxed environment without access to Node.js built-in modules like 'fs'. The native Fetch API, Web Crypto API, and URL parsing are supported in Edge runtime.

❓ component_behavior

intermediate

Behavior of environment variables in Edge vs Node.js runtimes

In Next.js, how do environment variables behave differently when using Edge runtime compared to Node.js runtime?

A Edge runtime inlines all environment variables at build time, unlike Node.js

B Edge runtime can dynamically read environment variables at runtime

C Node.js runtime does not support environment variables

D Edge runtime supports all environment variables at runtime like Node.js

💡 Hint

Consider when and how environment variables are injected in Edge runtime.

Edge runtime inlines all environment variables at build time, making them static. Node.js runtime can access all environment variables dynamically at runtime.

📝 Syntax

advanced

Correct way to specify Edge runtime in Next.js API route

Which code snippet correctly configures a Next.js API route to use the Edge runtime?

A

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

B

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

C

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

D

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

💡 Hint

Check the exact string used to specify Edge runtime in Next.js config.

The correct way to specify Edge runtime is using runtime: 'edge'. Other strings like 'nodejs', 'server', or 'edge-runtime' are invalid and cause errors.

❓ state_output

advanced

Output difference when using Node.js-only modules in Edge runtime

What happens if you import the 'crypto' module from Node.js in a Next.js Edge runtime API route and try to use it?

NextJS

import crypto from 'crypto';

export const config = { runtime: 'edge' };

export default function handler() {
  const id = crypto.randomUUID();
  return new Response(id);
}

A Throws a TypeError because 'randomUUID' is not a function

B Throws a ReferenceError because 'crypto' is undefined

C The code runs and returns a UUID string

D Throws a runtime error because Node.js modules are not supported in Edge runtime

💡 Hint

Think about module compatibility in Edge runtime.

Node.js built-in modules like 'crypto' are not supported in Edge runtime. Importing them causes runtime errors because the environment does not provide these modules.

❓ lifecycle

expert

Impact of runtime choice on cold start latency in Next.js API routes

How does choosing Edge runtime over Node.js runtime affect cold start latency for Next.js API routes deployed on Vercel?

A Node.js runtime has lower cold start latency because it uses persistent server processes

B Edge runtime generally has lower cold start latency due to lightweight serverless environment

C Both runtimes have identical cold start latency on Vercel

D Edge runtime has higher cold start latency because it compiles code on every request

💡 Hint

Consider how serverless environments differ in startup speed.

Edge runtime runs on lightweight, globally distributed serverless environments optimized for fast startup, resulting in lower cold start latency compared to Node.js runtime which uses traditional serverless functions with longer startup times.