Examples
An example is one finished job, for one target — a runtime, a framework, or a platform. It states what you are building, shows the complete files, then explains how they work.
That is a different shape from Docs, which explains one feature at a time — what a resource is, how params are read, where errors go. Those pages answer “how does this work.” These answer “I want to build X, show me the whole thing.”
Pick Your Runtime
Everything is filed under the runtime it runs on, because that is the choice you make once and keep. Open your runtime and every example under it is written for that runtime alone — no tabs to switch, no other runtime’s code on the page, nothing to click through to.
Each one carries the same set:
| Example | What you end up with |
|---|---|
| Basic App | One resource answering GET /. Start here; it is the smallest complete application. |
| Calling Claude | Two endpoints backed by the Claude API — one that answers at once, one that streams. |
| Calling OpenAI | The same two endpoints against Chat Completions. |
| Calling Perplexity | The same again, answering with the sources the reply was built from. |
| MCP Server | One resource speaking Model Context Protocol, publishing a tool, a resource, and a prompt. |
Node has three basic apps rather than one, because the module system is the only thing that changes the file: CommonJS, ESM, and TypeScript.
Frameworks
A framework owns the entry point. It decides what file your code lives in and what it is handed, and it is not tied to one runtime — a Next.js application runs on Node, Deno, Bun, and Cloudflare Workers.
That one is the only example here that also builds the browser half — a React component that renders the reply as it streams in.
Platforms
A platform is something you deploy onto rather than a runtime you build against. Both Vercel examples run on Node; what differs is the entry point Vercel expects.
What Changes Between Targets
The resource and the application are identical in every basic example. What differs is the entry point — see About > Concepts > Native vs. Polyfill — and how your target hands you a request. Worth a look before you pick, and not worth re-reading after.
| Entry point | What the resource receives | |
|---|---|---|
| Bun | http.polyfill.js | Web Request |
| Cloudflare Workers | http.native.js | Web Request |
| Deno | http.native.js | Web Request |
| Node (ESM / CJS / TS) | http.polyfill.js | Context object you build |
| Next.js (App Router) | http.polyfill.js | Web Request |
Vercel (api/) | http.polyfill.js | Web Request |
Vercel (server.ts) | http.polyfill.js | Context object you build |
Every basic example catches favicon requests in its .catch(). Browsers
request /favicon.ico automatically, and no resource owns that path, so the
chain throws a 404 for it. That check keeps the noise out of the console; it
is not something your own app needs.
What Every Example Assumes
- Your runtime is installed. If you do not have one yet, the quickstart sets one up.
- You have read the Docs — at least Creating a Resource, Handling Requests, and Error Handling.
That second one is a real assumption, not a courtesy. An example builds on the Docs rather than restating them: it links a concept the first time it comes up and then gets on with the job. Reading an example cold will work, but you will be following links to fill in what it does not stop to explain.
Each example names its own dependencies at the top and links out rather than repeating what another page already says.
Looking for a Walkthrough Instead?
These pages show finished work. If you want the reasoning built up step by step, read the step-by-step guide.