36  36. What Happens on the Server: Back Ends, Databases, and APIs

The browser shows the page, but much of the important work happens on servers you never see: remembering who you are, storing your orders, enforcing the rules. This page explains static vs. dynamic sites, what back-end code does, where data lives (databases), how logging in works, and how programs talk to each other (APIs).

36.1 Static vs. dynamic websites

• A static site sends files that were prepared ahead of time - the same HTML, CSS and JavaScript for every visitor. A portfolio, a restaurant menu or the hello-site from the previous page are static. (This book is too: its pages were turned into HTML files before you visited.) Static sites are simple, fast and cheap to host, and JavaScript can still make them interactive.
• A dynamic site runs code on the server for each request to build a response for that user at that moment: your order history, your bank balance, search results.

Two people can open the very same URL, such as an online store’s “Your orders” page, and see completely different content. That takes three things a static site doesn’t have: server-side code, a database, and a way to know who is asking (logging in).

36.2 Server-side code

Back-end code (or server-side code) runs on the server, not in the browser. It can be written in many languages: JavaScript or TypeScript (running on Node.js), Python, Java, C#, PHP, Ruby, Go and others.

When a request arrives - say, “sign me up for event 10” - the back end typically:

1. reads the request (method, path, data, cookies);
2. checks who the user is and what they are allowed to do;
3. applies the business rules (“an event can’t have more than 30 sign-ups”, “members can’t sign up twice”);
4. reads and writes the database;
5. maybe calls other services (send a confirmation email, charge a card);
6. sends back a response: a whole HTML page, or just data (usually JSON) for the front end’s JavaScript to display.

Because users never see back-end code, it is the safe place for secrets such as database passwords and API keys. Front-end JavaScript is the opposite: anyone can read it in DevTools.

36.3 Databases

A database stores data permanently and lets many users read and change it at the same time, safely and quickly. A database server program (for example PostgreSQL) manages it. Spreadsheets struggle with what apps need: thousands of users at once, millions of rows, rules that are always enforced, and control over who may see what.

36.3.1 Relational (SQL) databases

A relational database keeps data in tables - like Excel sheets, with rows and columns - and links tables through ID numbers. You ask it questions in SQL (Structured Query Language). Popular examples: PostgreSQL, MySQL, Microsoft SQL Server, and SQLite (a whole database in a single file, common in small apps and phones).

An events table:

id	title	date	capacity
10	Resume workshop	2026-10-20	30
11	Chess night	2026-10-22	16
12	Museum trip	2026-11-05	40

A SQL query that lists the bigger events, in date order:

SELECT title, date
FROM events
WHERE capacity >= 30
ORDER BY date;

The result is a small table:

title	date
Resume workshop	2026-10-20
Museum trip	2026-11-05

Sign-ups would live in a separate signups table with two columns, member_id and event_id: the row (1, 10) means “member 1 signed up for event 10”. Linking tables by IDs avoids repeating each member’s name and email on every sign-up.

36.3.2 Document (NoSQL) databases

A document database stores each record as a flexible, JSON-like document that can contain lists and nested data, and records don’t all need the same fields. Examples: MongoDB and Google’s Firebase Firestore. Relational databases are the usual default for business data; the database service used in this book’s tutorial, Supabase, is built on PostgreSQL.

36.3.3 Why the browser doesn’t talk to the database directly (usually)

To connect to a database you need its password, and anything in front-end code is visible to everyone. If the browser held the database password, any visitor could read or delete all the data. So the browser asks the back end, the back end checks who is asking and what they may do, and only then runs the query.

The exception: services such as Supabase and Firebase let front-end code read and write the database through their API using a key that is meant to be public. That is safe only because rules stored on the server - Supabase’s Row Level Security policies or Firebase’s Security Rules - decide exactly what each user may see and change. Without those rules, the data is exposed.

36.4 Logging in: authentication and authorization

Two words that sound alike but mean different things:

• Authentication - who are you? Proving your identity with a password, “Log in with Google”, or a code sent to your phone.
• Authorization - what are you allowed to do? Any member may sign up for an event; only club officers may delete one; you may see only your own orders.

HTTP has no memory: each request stands alone. So after you log in, the server gives your browser a session token, usually stored in a cookie. The browser sends that cookie back automatically with every request to the site, and the server uses it to recognize you. Logging out ends the session.

Two rules of thumb: a well-built system never stores passwords as plain text (it stores a scrambled, one-way “hash” of each one), and you should not build your own login system - use a proven service such as Supabase Auth, Firebase Authentication, Auth0 or Clerk. “Log in with Google” is explained in APIs, API Keys, and Third-Party Services.

Deeper dive: What a session cookie looks like

After a successful login, the response includes a header like this (the value is a long random string):

Set-Cookie: session_id=8f2c1e9a...; HttpOnly; Secure

From then on, every request the browser sends to that site carries it:

GET /my-events HTTP/1.1
Host: clubs.example.com
Cookie: session_id=8f2c1e9a...

HttpOnly means JavaScript running in the page can’t read the cookie, and Secure means it is only sent over HTTPS. Whoever holds this value is “you” to the server, which is why you should never paste cookies anywhere.

36.5 APIs: programs talking to programs

An API (Application Programming Interface) is a defined way for one program to ask another program for data or actions. Think of a restaurant menu: it lists what you can order and how to ask for it, without telling you how the kitchen works.

Web APIs use HTTP. A program sends a request to a URL, called an endpoint, and gets back data instead of a web page - almost always in JSON (JavaScript Object Notation), a simple text format for data:

{
  "id": 10,
  "title": "Resume workshop",
  "date": "2026-10-20",
  "capacity": 30,
  "spotsLeft": 12,
  "tags": ["career", "workshop"],
  "online": false
}

Curly braces { } hold an object made of "name": value pairs; square brackets [ ] hold a list; text goes in double quotes; numbers, true, false and null don’t.

Who calls APIs? Your own front end (the page’s JavaScript asks your back end for the list of events), mobile apps, and your back end itself when it uses other companies’ services such as payments or AI.

36.5.1 REST in one paragraph

Most web APIs follow a style called REST: each kind of thing (a resource, such as events) gets a URL, and the HTTP method says what to do with it. The four basic actions - Create, Read, Update, Delete - are often called CRUD:

Request	Meaning
GET /api/events	Read: list all events
GET /api/events/10	Read: get event 10
POST /api/events	Create: add a new event (its data goes in the request body)
PATCH /api/events/10	Update: change some fields of event 10 (PUT replaces it entirely)
DELETE /api/events/10	Delete: remove event 10

36.6 The typical “stack”

Put together, most web apps look like this:

 +------------------+           +------------------------------+
 |  Browser         |   HTTPS   |  Back end (your server code) |
 |  front end:      | <-------> |  - who is this? (auth)       |
 |  HTML, CSS, JS   |   JSON    |  - business rules            |
 +------------------+           +------------------------------+
                                     |                  |
                                     v                  v
                           +----------------+  +-----------------------+
                           |  Database      |  |  Third-party APIs     |
                           |  (PostgreSQL)  |  |  payments, email, AI  |
                           +----------------+  +-----------------------+

The particular technologies chosen for each layer are called the stack - for example, “Next.js and Supabase, hosted on Vercel”. The next pages cover each layer: frameworks (Web Frameworks and Meta-Frameworks), third-party services (APIs, API Keys, and Third-Party Services) and hosting (Hosting and Deployment).

Practice Questions

Easy

Question 1 · Multiple choice

Which of these requires a dynamic site?

1. A restaurant’s menu page
2. A student’s portfolio
3. A page showing your current bank balance
4. A company’s “About us” page

Suggested answer

c. The balance is different for every user and changes over time, so the server must run code, look you up in a database and know who you are. The others show the same content to everyone and can be static files.

Question 2 · Classify

Label each situation as authentication or authorization.

1. Entering your password on the login page
2. Only officers see the “Delete event” button
3. Clicking “Log in with Google”
4. You can view your own orders but not anyone else’s

Suggested answer

1 authentication, 2 authorization, 3 authentication, 4 authorization. Authentication is proving who you are; authorization is deciding what you may do.

Question 3 · Short answer

What is a database? Name one relational database and one document database.

Suggested answer

A database stores data permanently and lets many users read and change it safely at the same time. Relational examples: PostgreSQL, MySQL, SQLite, Microsoft SQL Server. Document examples: MongoDB, Firebase Firestore.

Question 4 · True or false

It is safe to put the database password in the front-end JavaScript as long as the file has an unusual name.

Suggested answer

False. Every file the browser downloads can be read by anyone (for example in DevTools), whatever its name. With the password, a visitor could read or delete all the data. Secrets belong on the server.

Question 5 · Multiple choice

What is an API?

1. A type of database
2. A defined way for one program to request data or actions from another
3. A programming language for servers
4. The part of a URL after the ?

Suggested answer

b. An API is like a menu of requests a program accepts. It is not a database (a) or a language (c); (d) describes a query string.

Question 6 · Short answer

What is JSON, and what do { } and [ ] mean in it?

Suggested answer

JSON (JavaScript Object Notation) is a simple text format for sending data between programs. { } holds an object made of "name": value pairs, and [ ] holds a list of values.

Medium

Question 7 · Read the JSON

Using the event JSON shown on this page: How many people can still sign up? How many tags does the event have? Is it online?

Suggested answer

12 spots are left ("spotsLeft": 12). It has two tags, "career" and "workshop". It is not online ("online": false).

Question 8 · Predict the output

Using the events table on this page, what does this query return?

SELECT title
FROM events
WHERE date < '2026-11-01'
ORDER BY capacity;

Suggested answer

Two rows: Chess night (capacity 16) and then Resume workshop (capacity 30). The Museum trip is filtered out because its date is in November; ORDER BY capacity sorts the rest from smallest to largest capacity.

Question 9 · Matching

Match each REST request with what it does.

Request		Action
1. GET /api/events/7		A. Delete event 7
2. POST /api/events		B. Change some fields of event 7
3. PATCH /api/events/7		C. Get event 7
4. DELETE /api/events/7		D. Create a new event

Suggested answer

1 → C, 2 → D, 3 → B, 4 → A.

Question 10 · Scenario

Which status code fits each case, 401 or 403? (a) A visitor who is not logged in requests /my-events. (b) A logged-in member tries to delete an event, which only officers may do.

Suggested answer

1. 401: the server doesn’t know who the visitor is (authentication is missing). (b) 403: the server knows who the member is but the member is not allowed to do this (authorization fails).

Question 11 · Short answer

HTTP “has no memory”. How does a site still know you are logged in when you click from page to page?

Suggested answer

At login, the server creates a session and gives the browser a token, usually in a cookie. The browser automatically sends that cookie with every later request to the site, and the server looks it up to recognize you.

Question 12 · Ordering

Put the back end’s steps for “sign me up for event 10” in a sensible order: (a) save the sign-up in the database, (b) check who the user is, (c) send back a response, (d) check that the event isn’t full, (e) send a confirmation email.

Suggested answer

b → d → a → e → c. First identify the user, then apply the business rule (capacity), then save, then trigger the email, then answer the browser. (Sending the response before the email also works, as long as the save has succeeded.)

Hard

Question 13 · Scenario

A classmate’s app shows “Spots left: 3” and hides the sign-up button when an event is full - but only in the front-end JavaScript. The back end saves any sign-up it receives. What can go wrong, and where should the rule be enforced?

Suggested answer

Front-end checks are easy to bypass: anyone can send requests directly (with curl or DevTools), and two people can click “Sign up” for the last spot at the same moment. The event can end up over capacity. The rule must be enforced on the back end (ideally also by the database, for example with a constraint), which checks the current count before saving. The front-end check is still nice for the user, but it is not protection.

Question 14 · Scenario

A Supabase app’s front-end code contains a key that anyone can see in DevTools. A teammate panics. When is this acceptable, and what must be true for the data to be safe?

Suggested answer

It is acceptable if that key is the one designed to be public (Supabase’s publishable key) - never the secret key. It is safe only if Row Level Security policies on the server restrict what each user may read and change. Without those policies, anyone with the public key could access the data.

Question 15 · Long answer

A club tracks sign-ups in one big spreadsheet: each row repeats the member’s name, email and phone, plus the event’s title, date and room. Explain why a relational design with three tables (members, events, signups) is better.

Suggested answer

• No repetition: each member’s details and each event’s details are stored once; signups only stores the two IDs.
• Easy, consistent updates: if a member changes their email or an event moves rooms, you change one row, not dozens (and can’t miss some).
• Easier questions: “who signed up for event 10?” or “how many events did Maria attend?” become simple queries.
• Rules and safety: the database can enforce rules such as “no duplicate sign-ups”, and many users can work with the data at the same time safely.

Question 16 · Compare

Your team must choose between a relational database (PostgreSQL) and a document database (MongoDB) for a club app with members, events and sign-ups. Give one argument for each, and say which you would pick.

Suggested answer

• PostgreSQL (relational): the data is naturally tabular and connected (members ↔︎ sign-ups ↔︎ events); SQL handles those links and rules well; it is the usual default for business data and is what Supabase provides.
• MongoDB (document): flexible documents are convenient when records vary a lot in shape or are naturally nested, and you can change their fields without redesigning tables.

For this app, PostgreSQL is the better fit because the data is structured and relational. A good answer justifies the choice with the shape of the data.

Question 17 · Scenario

A website shows your name at the top of every page. Using the terms session, cookie and database, explain how the server knows which name to put there on each request.

Suggested answer

When you logged in, the server created a session and sent your browser a cookie with the session’s ID. On every request the browser sends the cookie back. The back-end code looks up that session to find your user ID, reads your name from the database (or the session data), and inserts it into the page (or into the JSON the front end displays).

Question 18 · Long answer

Pick an app you use (for example a food-delivery or ride-sharing app). Sketch its stack: what runs in the front end, what the back end does, what the database stores, and which third-party APIs it probably uses.

Suggested answer

Example for a food-delivery app:

• Front end: the app’s screens - restaurant lists, menus, cart, order tracking map.
• Back end: logins, prices and delivery fees, assigning drivers, order status updates, refunds (the business rules).
• Database: users, restaurants, menu items, orders, drivers, ratings.
• Third-party APIs: payments (for example Stripe), maps and directions, text messages or push notifications, email receipts, possibly AI for support chat.

A good answer puts secrets and rules in the back end and names realistic external services.