01FRONTEND
The web page
What your user sees
Acme HelpdeskDemo
Support tickets
3Load tickets from the database into this page.
Page is ready. Choose an action to begin.
The page talks to the API. The API talks to the database.
FROM A CLICK TO A ROW
See what happens behind the page.
Make a change. Follow the request. Watch your tables respond.
Interactive simulationSample data · no live database connection
EXPLORE
YOUR REQUEST JOURNEYReady when you are
1Page action
2API request
3Prepare query
4Read / change rows
5Database result
6API response
7Page updates
02BACKEND
The API
The bridge to your data
GET
/api/ticketsReceives the page’s request and decides what to ask the database.
REQUEST PAYLOAD
No request yet
RESPONSE
Waiting for a result…
↳ The API validates input and returns only the data the page needs.
03DATABASE
PostgreSQL
Where structured data lives
Highlighted rows are involved in this action.
public.users 3 rows
idintegerPK
nametextNOT NULL
1 user↓ owns many ticketsusers.id = tickets.owner_id
public.tickets 3 rows
idintegerPK
titletextNOT NULL
statustextopen / resolved
owner_idintegerFK → users.id
A schema groups related tables. A table stores rows. A primary key (PK) identifies a row; a foreign key (FK) links it to another table.
WHAT THE DATABASE IS ASKED TO DO
Read ticket records. Nothing is changed by a read.
Peek at the SQL
SELECT * FROM public.tickets ORDER BY id;
START HERE
A small action. A complete round trip.
Try “Run journey” to load tickets. The page, API, and database will light up in order. Use “Step” to move one stage at a time.
Journey log
CAUSE → EFFECT- Your request’s story will appear here, one step at a time.
What changed?
NO ACTION YETWatch the database change before the web page catches up.
Row One recordColumn One propertyTable A collection