sxsphinxstack

Skills / Backend basics

Backend basics

Build and deploy their first small server. Covers a few real endpoints, frontend requests, current host limits, server-side secrets, and failure handling. Use when a frontend needs a hidden key, when they ask "what is a backend", or when localStorage stops being enough.

Use this skill. Nothing to install.

Open in ChatGPT Open in Claude prefilled and ready; just hit send
for Gemini, Copilot, or Cursor: paste it, then say "use the backend basics skill"

Don't have an agent?  ·  Raw file: skills/backend-basics.md

Watch the first two minutes

This is how a session goes, including the part everyone is afraid of. Click through it.

(pastes the skill) my weather page needs to hide its API key. do i need a backend?
You do, and it's smaller than the word makes it sound. First: what does the page do today, and where does the key live right now?
it's a static page and the key is just sitting in the js file. honestly "server" scares me, i've never touched one
A server here is a small function on a free host that answers HTTP. You'll write maybe thirty lines. The shape: browser calls your API, your API calls the weather service with the hidden key, JSON comes back. That's the whole job.
don't i have to pay for hosting?
No. Free tiers cover this, and I'll name their limits before you sign up: request caps, and instances that sleep when idle. No card details anywhere; if a host demands a card even for the free plan, we pick another host.
ok, where do we start
One hello endpoint that returns JSON, running locally, hit with curl and with the browser so both feel the same. Then we deploy that before writing anything else. A live URL in the first half hour keeps the rest honest.

Scripted example of a real session.

I've never touched a server

Nobody has until the first one. The skill makes "server" concrete: code that runs on a machine that is always on, holds secrets the browser can't see, and answers HTTP requests. You build two or three endpoints that serve a real need from your existing project, you run every deploy and every curl yourself, and the agent narrates what each command does in one line before you run it. These projects each hide a real backend behind them:

Speedrun game with a real leaderboard Turn-based game two browsers can play Booking system for a tutor or coach

What you end up with

An API of your own at a live URL, with your frontend calling it. Here is a finished one for the weather page above: two endpoints, secrets server-side.

Example
YOUR API, DEPLOYED AND ANSWERING
$ curl https://maya-api.example.com/api/weather
{"temp_f":74,"condition":"clear","cached":true}
THE ROUTE BEHIND IT (EXCERPT)
app.get("/api/weather", async (req, res) => {
  const r = await fetch(UPSTREAM_URL, {
    headers: { "X-Api-Key": process.env.WEATHER_KEY },
  });
  if (!r.ok) return res.status(502).json({ error: "weather source down" });
  res.json(await pickFields(r));
});
THE UNHAPPY PATH, TESTED WITH CURL
$ curl "https://maya-api.example.com/api/weather?city=%20"
HTTP 400 {"error":"city must be a non-empty name"}
  1. The key never reaches the browser. It lives in the host's env-var settings and a gitignored local .env. Open dev tools on the frontend and there is nothing to find.
  2. Bad input gets a 400 with a message. You test the failure yourself with curl, so the first user to type garbage isn't the tester.
  3. Two endpoints, complete. The skill holds the line at two or three. A backend that does one job completely beats a scaffold with ten empty routes.

Questions people actually ask

Is a server a machine I have to buy or rent?

Not here. You deploy to a free tier: serverless functions or a small Node app on a free host. It runs on someone else's always-on machine, and the free tier's limits are named honestly before you commit to one.

What is CORS and why did the browser block my request?

Browsers refuse to let a page call an API on a different domain unless that API says it's allowed. Your API sends a header granting your frontend permission. The skill expects CORS to bite during wiring and has you fix it and explain why the browser blocked the call in two sentences.

What happens when the free tier sleeps?

Some free hosts idle your instance after inactivity, so the first request after a quiet spell is slow while it wakes. That's the honest price of free, and the skill says so up front. For a personal project it is usually fine; serverless functions mostly avoid it.

Can people hack my API?

Anyone can send it requests, which is why the skill treats unhappy paths as part of the build: bad input gets a 400, a down upstream gets caught, secrets stay in env vars on the server. With two endpoints doing one job, the surface stays small enough to reason about.

Do I have to know Node?

You need the JavaScript you already have from building a frontend. The endpoint code is short, and the agent explains each piece as you write it. If you have no frontend yet, run build a web app first or build the pair together.

Where to go from here

Your API works. Now give it memory and users:

Database basics: survive a redeploy Auth basics: who sees what Use an API: richer upstream data

Or build something with a backend at its heart:

Order desk Quiz battle League office

Ideas to use it on

Curious? Read the full skill — the exact instructions your agent gets 
---
name: backend-basics
category: code
description: Build and deploy their first small server. Covers a few real endpoints, frontend requests, current host limits, server-side secrets, and failure handling. Use when a frontend needs a hidden key, when they ask "what is a backend", or when localStorage stops being enough.
---

# 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. Then pick the two endpoints this project needs.
2. Hello endpoint, locally: one route returning JSON. Hit it with
   curl and with the browser so both feel the same.
3. Deploy that hello endpoint before writing anything else. Free
   tiers make this a ten-minute step; a live URL early keeps the rest
   honest.
4. Real endpoints: the private fetch with the hidden key, or the
   shared read/write the project needs. Env vars set in the host
   dashboard by them, mirrored in local `.env`.
5. Wire the frontend to it with `fetch`. Handle CORS when it bites
   (it will) and explain in two sentences why the browser blocked the
   call.
6. Unhappy paths: bad input gets a 400 with a message, a down
   upstream gets caught, and they test both with curl.

## Done

- A deployed API at a URL, written by them, with 2 to 3 endpoints
- Their frontend calling it and rendering the result
- Secrets only in host env vars and a gitignored `.env`; nothing
  secret in the repo or the browser dev tools
- They can trace one request from click to response out loud

Then: database-basics when the API needs memory that survives a
redeploy, or auth-basics when different users should see different
things.