Vefskólinn · Back-end · act one and act two

Where does
it live?

Your app works on one screen. Now make it real: shared, and safe.

press → to begin

Where we are

Where this fits

JavaScript FrameworksOne app, three times, with an AI agent. Saved in localStorage

→

Where does it live?This guide. The same app gets a server, a database, and a secret to keep

→

Group project · 28 SeptAny stack. Now with a back end when you need one

an app in React, Vue or Angular a list, a form, something saved a site on GitHub Pages fetch() from the Web APIs guide a terminal agent that writes code with you you describe, the AI builds, you decide

A server exists for exactly two reasons: shared truth and trust. Act one is the first, act two is the second.

Who does what

Three people, one product

Click a person. Or the card below for how they hand work to each other.

The problem

Your app lives on one screen

laptoplocalStorage

a server

move the list to a server

phonelocalStorage

localStorage is storage inside one browser on one device. Refresh survives. Sharing does not.

The vocabulary

Five words, and only these five

Click a word. Each one is a program or a rule, nothing more mysterious than that.

One request, start to finish

Request out, response back

browser

HTTP

GitHub's server

reads a file from disk

the files you pushed

// the request

// the response

Reading the response

What did the server say?

2xx it worked · 3xx go elsewhere · 4xx the request was wrong · 5xx the server broke. Read the number first, then everything else. every code as a cat ↗ …or as a dog ↗

The rule

Four questions, any yes → server

01Shared?

Does more than one person, or more than one device, need to see the same thing?

the book list, the likes, the leaderboard

02Survives?

Must it still exist when this browser is closed, cleared or lost?

anything you'd be sad to lose

03Trusted?

Could the browser lie about it, and would that matter?

prices, who owns what, who is logged in

04Secret?

Would it be bad if a stranger read it in view-source?

API keys, passwords, database addresses

Four times no? Leave it in the browser. It's faster, free, and works on the bus. Write the answer down for every piece of data in your app: that list is your boundary map, and it is the first thing you make in act one.

The game

Where does it live?

Round 1 of 10

…

Ask the four questions. Shared? Survives? Trusted? Secret?

score0/ 10

Tie-breakerIf the browser could lie about it and that would matter, it lives on the server.

The database

A database outlives everything

✓Close the tab? Still there. Restart the server? Still there.
✓Only the server talks to it. The browser asks the server, never the database.
✓Two families. The agent will pick one. Ask it why, accept either. Depth in January.
✗Not a file in your repo. Not localStorage. Not a variable in the server that dies on restart.

Act one

Make it shared

the prompt, roughly

“Move my book list out of localStorage and onto a server with a real database, so that my laptop and my phone show the same list. Keep the front end in Vue. Put the database address in an environment variable, and deploy it so I can open it from my phone. Explain every file you create.”

1
Boundary map firstevery piece of data, browser or server, and which question decided it
2
Four requirementsa server you can read logs from · a database · one environment variable · a public URL
3
Then ask “where does the data live now?”and make it show you. Every file it made, explained.

⇄

the laptop-and-phone test

Add on one. See it on the other. That is the pass mark.

If it says localStoragesend it back. That is the thing we are replacing.

The evidence

Open the network tab

NameMethodStatusType

Click a row.

Every row is one request and its response.

In your report: one request, annotated. What went out, what came back, and why the status is what it is. If it isn't in the network tab, it didn't happen.

Act two

Now add a brain. Where's the key?

browser

POST api.model.com/v1 …

your server

POST api.model.com/v1

the model

what the network tab shows to anyone who opens your site

Secrets

Secrets live in .env, on the server

.env server only · never committed

MODEL_API_KEY=sk-live-8f3…d21
DATABASE_URL=postgres://…@host/books

.gitignore

node_modules
.env
.env.*
!.env.example

server.ts

const key = process.env.MODEL_API_KEY
if (!key) throw new Error("no key set")

.env.example this one IS committed

MODEL_API_KEY=put-your-key-here
DATABASE_URL=put-your-db-url-here

Trap 1 · the public prefixVITE_ and NEXT_PUBLIC_ mean “copy this into the browser”. An agent will use them to silence an error. Say no.

Trap 2 · the hostOn Render, Railway, Vercel… you type the value into their dashboard. The file never travels.

Trust

The server doesn't trust the browser

The browser can say anything. The server decides what is true. Identity, ownership, shape, and how often. Every check is one line the agent will happily write, once you ask.

Day two, after lunch, one hour

The attack hour

Rules

✓Classmates' deployed apps on the class list, nothing else
✓Only the moves on this card
✓Found it? Stop. Write down exactly what you did. Tell them kindly.
✗No guessing passwords, no tools, no touching anything that isn't in the game

Find a keyin the repo, the network tab, or view-source

5

Change or delete something that isn't yoursedit the URL, change the id

3

Spend their quotacall the AI feature 100 times from a loop in the console

3

Break it with inputempty title, 20,000 characters, negative number, emoji, broken JSON

2

Read data you shouldn't seeanother user's list, a hidden field, an error message with the DB address in it

3

Every point you score is a fix you owe your own app. Then the incident note: what was found, how, what you changed.

When, not if

You committed a key

time since push0:00bots are already reading it

Assume it's stolen. Public GitHub is scanned in seconds. Don't debate it.
Rotate first. Go to the provider, make a new key, revoke the old one. Now the leak is over.
Then move it. New key into .env, check .gitignore, set it in the host's dashboard.
Tell the team. They need the new value, and they need to know.
Rewriting history is optional. It tidies up. It un-leaks nothing. Git remembers, and so does whoever cloned.

Hosting

Where does the server run?

the server

Rendergit push, it builds, you get a URL. Logs and env vars in the dashboard.

Railwaysame idea, nice logs, database one click away.

Fly.iocloser to the metal, runs anywhere on earth.

Vercel · Netlify · Cloudflareyour front end's host can run small server functions too.

the database

Neon · Supabasehosted Postgres, one URL to paste into .env.

Tursohosted SQLite. Tiny, fast, generous free tier.

MongoDB Atlashosted documents, like the JSON on the database slide.

you decide with three questions

Can I read the logs?no logs, no debugging. non-negotiable.

Can I set environment variables?that's where the secrets go.

Is it free for a school project?and does it want a card? check before, not after.

the agent picks, you approve

The server has no screen

Find the 500

Something went wrong once.

Click the line that tells you what.

Read upwardFind the error, then read the lines above it: which request, what it tried, what it got.

Your report

A web page, with evidence

my-app · where does it live?

Try itLink to the live app and a QR code. The reviewer opens it on their phone in ten seconds.

The boundary mapEvery piece of data and action: browser or server, and which of the four questions decided it.

One request, annotatedA network tab screenshot with arrows: what went out, what came back, why that status.

Where the key livesThe AI feature, the .env.example, and proof the network tab shows no key.

Attack hour · found and fixedWhat classmates got into, and the line you changed for each. The incident note if a key leaked.

What the AI got wronglocalStorage again? a public prefix? trusted the browser? Every catch is a lesson.

Evidence beats proseScreenshots of the network tab and the logs. Real URLs. Real status codes.

The reviewer runs the testsLaptop-and-phone test, then two moves from the attack card. Written feedback on both.

Group project on MondayWhatever you learn here, you may use there from day one.

Hand-in

What you deliver

1
One repo: app + server, deployeda public URL that passes the laptop-and-phone test, with .env.example and no real key anywhere in git
2
The report, as a web pagereport/index.html in the repo and published: boundary map, one annotated request, where the key lives, what was found and fixed
3
Two peer reviewsopen two classmates' apps on your phone, run the test, try two moves from the attack card, leave written feedback in the LMS
4
Your replyfix what the reviewers found and say what you changed

Day 1

Act one. Boundary map, then the prompt. Server, database, one env var, deployed. Laptop-and-phone test passes before you leave.

Day 2

Act two. The AI feature, the key in .env, the trust checks. Attack hour after lunch. Score points, owe fixes.

Day 3

Fix, write, review. Close what was found. Report with evidence. Two reviews, then your reply. Group project starts Monday.

Shared truth. Trust.

that's why there's a server

MDN · HTTP overview MDN · status codes roadmap.sh/backend the guide in the LMS

`→` `space`	next step
`←`	previous
`Home` `End`	first / last slide
`N`	speaker notes
`F`	fullscreen
`B` `S`	on the game: answer Browser / Server
`?`	this help

Where doesit live?