How do you implement response streaming in a Next.js Route Handler?

WHAT THIS TESTS: This question probes whether you understand the standard Web Streams API inside Next.js App Router Route Handlers. Interviewers want to see that you know how to avoid buffering entire payloads in memory, that you understand the pull versus push model of streams, and that you can reason about runtime constraints. In Next.js, Route Handlers return a standard Web Response object, so Node-specific patterns like res.write do not apply unless you are in a custom server outside the App Router.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, instantiate a new ReadableStream with a start function that receives a controller. Second, use a TextEncoder to convert string chunks into Uint8Array bytes and call controller.enqueue for each chunk. Third, return a new Response object where the body is that ReadableStream, optionally setting headers like Content-Type to text-plain or text-event-stream. Fourth, ensure the controller is closed in a finally block or when the source ends to prevent hanging connections. For use cases, mention AI chat interfaces where tokens arrive incrementally, or streaming large JSON arrays from a database cursor without loading everything into memory. You should also mention that the Edge runtime supports Web Streams natively, while the Node runtime in Next.js also supports them but you must avoid mixing Node streams directly.

COMMON WRONG ANSWERS: A common wrong answer is suggesting res.write from the old Pages Router API paradigm or trying to pipe a Node fs.createReadStream directly into the Response without wrapping it in a ReadableStream. Another red flag is forgetting to handle backpressure or failing to close the controller, which leaves the HTTP connection open indefinitely. Some candidates also confuse React Server Components streaming with Route Handler streaming; these are different layers.

LIKELY FOLLOW-UPS: An interviewer might ask how you would handle backpressure if the consumer is slower than the producer. They might ask how to stream from an external fetch call that itself returns a ReadableStream, which involves piping one stream into another. They could also ask about error handling mid-stream or how to set headers for Server-Sent Events versus standard chunked transfer encoding.

ONE CONCRETE EXAMPLE: Imagine a Route Handler at app/api/chat/route.js that proxies an LLM API. You create a ReadableStream, and inside the start function you make a fetch to the LLM endpoint. You read the external response body reader in a loop, decode chunks, enqueue them into your controller, and close when the external reader is done. You return new Response stream with headers set to text-event-stream. This keeps your Next.js server memory flat even if the response is ten thousand tokens long.