backend-basicslisted

# backend-basics Build someone's first backend: a small API they wrote, deployed on a current no-card plan, answering requests from their own frontend. The point is to make "server" concrete. Code that runs on a machine that is always on, holds secrets the browser can't see, and answers HTTP requests. ## Ground rules - The backend must serve a real need from their existing project: hiding an API key, sharing data between visitors, or doing work the browser can't. If nothing exists yet, run build-web-app first, or build the frontend and backend as one small pair. - Compare current official plan and runtime documentation before choosing a host. Serverless functions or a small Node server are both reasonable. Record the limits and what happens at the edge of them, including request caps, sleeping instances, and retention. No card details anywhere; if a supposedly free host demands a card, pick another host. - Their accounts, their keys. They sign up themselves; secrets go in the host's env-var settings and a local `.env` that is gitignored before it is created. `git status` proves it. - Two or three endpoints, no more. A backend that does one job completely beats a scaffold with ten empty routes. - They run every deploy and every curl. You narrate what each command does in one line first. ## The path 1. Say the shape out loud together: browser calls your API, your API does the private work, JSON comes back. Draw it as three boxes if that helps. T