How does code reach what it needs?

Next.js lets a component await its data, on the server or in the browser. What is await actually doing, why does the browser need an API when the server doesn't, and where does the data come from when the database belongs to another company?

The same question, asked of a different program: Claude Code is a command like ls, and it can be given plugins and settings. Where do those go, and how does it find them? Both halves come down to place. This picks up from What does Next.js do with my code?, which explains Server and Client Components, and How does my terminal find a tool?, on how a command is found.

Fetching data means waiting: a request goes out over the network and the answer comes back some hundreds of milliseconds later. JavaScript runs on one thread, so if it simply stopped and waited, nothing else could happen meanwhile; in a browser the page would freeze. Instead it hands the wait to the system and carries on, and the event loop¹³ runs the code waiting for the answer when it arrives.

Saying what to do when it arrives has been written three ways. First callbacks: pass a function to be called with the answer. Steps that depend on each other nest inside each other, and three deep it is hard to read. Then promises: a promise⁴⁰ stands for an answer that isn't here yet, and .then() says what to do with it. Then async and await, which is promises written as if nothing waited at all.

await pauses the function it is in until the promise settles, then carries on with the value. Only that function pauses; the rest of the program keeps going. A function marked async may use await, and always returns a promise itself. Three dependent steps become three lines in order: get the user, then their posts, then the comments on the first post.

The catch is that await waits even when it doesn't need to. Three requests that don't depend on each other, awaited one after another, take as long as all three together. Started together and awaited together with Promise.all, they take as long as the slowest.

const user = await getUser()
const weather = await getWeather()
const news = await getNews()

A Server Component³⁶ can be async and await its data inside itself. The await runs on the server, before anything is sent, so the HTML arrives with the data in it and the visitor never sees a gap. A Client Component³⁷ can't be async. It renders first with nothing, starts the fetch from a useEffect once it is in the browser, and renders again when the data arrives, so it needs something to show in between.

• Fetch on the server when the data is the same for everyone (an article, a product, documentation), and whenever the fetch needs a secret.
• Fetch in the browser when the data only exists there or has to stay live: what someone types into a search box, a feed that updates every second, the size of their window.
• Personal is not the same as client. The server can read the visitor's cookies, so a page that differs per person can still arrive with its data in it.

Start on the server. Move a piece to the browser when it has to react to the person using it. One page usually has both: a product's details fetched on the server, its live stock count in the browser.

It looks as if the server reaches the database directly and the browser has to go through an API. But the database is rarely in the same place as the server. A Next.js site on Vercel with its data on Convex makes a network call either way. The difference is who makes the call, and whether they can be trusted with the key.

A database lets in callers that show a secret key. Code on your server can hold that key: it never leaves the server, and nobody can read it. Code in the browser runs on the visitor's own machine, where everything it has can be read in the developer tools, so the browser can't be given the key. So it asks your server instead, through an address you make for it (in Next.js, a Route Handler such as /api/posts), and your server makes the call with the key and sends back only the answer.

It was never API or no API. It is where the call is made from, and whether that place can keep a secret.

Services built to be called from the browser, Convex and Supabase among them, give the browser only an address or a public key that names the project, and their own rules decide what each signed-in person may read. Anything that must stay secret still stays on a server.

Claude Code is a command-line tool like ls or curl: one file on PATH²⁴, ~/.local/bin/claude, installed the way Bun is. The difference is what it does with what you type. ls -la does the same thing every time: the arguments³⁰ pick from behaviour written in advance. Claude Code takes a sentence, and a language model decides what to do: which files to read, what to change, which other commands to run. It runs ls, git and curl itself. It is a tool that uses tools, the harness⁰³ round a model from Three layers.

Inside it, a line starting with / is one of Claude Code's own commands, not the shell's, the way :wq means something only inside Vim. /plugin is one of them.

A plugin adds to what Claude Code can do: skills it can follow, commands, hooks that run at set moments, connections to other services. Adding one takes two commands, because there are two things to add.

• /plugin marketplace add bradautomates/claude-video adds a marketplace: a catalogue of plugins, here a GitHub repository. Claude Code copies it to ~/.claude/plugins/marketplaces/claude-video and remembers it in known_marketplaces.json. Nothing is installed yet; the name is grander than the thing, which is a list, like the one npm or Homebrew read from.
• /plugin install watch@claude-video installs one plugin, watch, from that marketplace. Its files go to ~/.claude/plugins/cache/claude-video/watch/0.2.0/, one folder per version, and a line "watch@claude-video": true goes into enabledPlugins in a settings file. From the next session, Claude Code loads it.

That plugin shows what most are: instructions plus a few ordinary commands. To watch a video, it runs yt-dlp to download it, ffmpeg to cut frames out of it as images, and takes the words from its captions or a speech-to-text model. The model can read images and text, not video, so the plugin turns the one into the other.

npx plugins add vercel/vercel-plugin is a third way in, and not Claude Code's at all. It runs an npm package called plugins, which converts a plugin written in a format several agents share into each agent's own, then installs it through that agent's own plugin system. It downloads the source to ~/.cache/plugins first; what reaches Claude Code ends up in the same folders as above.

Claude Code is installed once, for you. Its settings, and the plugins they switch on, can sit in three places, and the place decides who gets them.

When you start claude in a folder, it reads your user settings, then that project's .claude/settings.json, then .claude/settings.local.json; where two disagree, the more local one wins. The project's file is committed, so everyone who clones the project gets the same plugins and rules. The local one is git-ignored and only yours. CLAUDE.md files follow the same pattern, and those are also read from the folders above where you started.

Not everything lives in settings.json. Connections to other services (MCP servers) are kept in ~/.claude.json for you, or .mcp.json in a project. And ~/.claude holds more than settings: projects/ keeps each project's transcripts and memory, skills/ your own skills, plugins/ all of the above.

npm makes the same choice between you and a project. npm install prettier puts it in the project's node_modules and records it in package.json, so it goes wherever the project goes. npm install -g prettier puts it in one place for you: under npm's prefix, the files in lib/node_modules/prettier and a symlink²⁵ in bin so the shell can find it. The prefix is wherever the Node that runs npm says, so it isn't always /usr/local: with a Node installed in your home folder it is often ~/.local, and npm config get prefix says which.

npx prettier runs a package's command without installing it. It looks in the project's node_modules/.bin first. If it isn't there, npx downloads it into a cache, ~/.npm/_npx, and runs it from there. Nothing is installed for good, but it isn't gone either: the next run finds it in the cache.

Claude Code's own installer takes the third way from Two ways to move in: a folder of its own in your home, ~/.local/share/claude, and one link on PATH. Its settings then take npm's two places: ~/.claude for you, .claude for a project.

Both halves were the same question. A component reaches data according to where it runs: on the server it can hold keys, in the browser it can only ask. Claude Code reaches tools and settings according to where they sit: a file in ~/.claude is yours everywhere, a file in a project's .claude belongs to everyone who has the project.

Code reaches what is where it looks, and is allowed what the place it runs can be trusted with.