3.A.1 What The Backend Solves

The frontend runs in the user's browser. The user's computer is the frontend's turf, and the code, variables and calculations are all visible and editable the moment the user opens the browser's developer tools.

The consequence is direct: anything that must not be seen or tampered with by the user cannot be handled on the frontend alone. Passwords, other people's data, business logic that needs to stay private, all of this has to be handled somewhere the user cannot reach. That place is the backend, which is really another computer called a server.

A concrete example: if an order's total is calculated on the frontend and then sent to the backend to store, the user only has to open developer tools and change the total being sent to 0.01. If the backend simply trusts that number, it lets the user decide how much to pay. The safe way is for the backend to recalculate the total itself once it has the order, never trusting the figure the frontend sends. This idea matters, and the exercise unpacks it.

3.A.2 How A Server Works: Request And Response

The frontend and backend communicate through a constant back-and-forth of requests and responses.

Using the food-ordering app: the user taps "Place order", the frontend wraps the order into a request and sends it to the backend. The backend receives the request, processes it, wraps the result into a response, and sends it back. The frontend takes the response and shows the result to the user. The diagram above shows the stages a request actually goes through once it reaches the backend.

This "request comes in, process, response goes back" pattern is the skeleton of almost all backend code. Whenever you see a piece of backend code, first ask yourself: which stage of the request is this handling?

3.A.3 HTTP Methods And Status Codes

A request tells the backend "what I want to do" through an HTTP method:

• GET: ask for data, like "show me the menu".
• POST: send data, usually to create something, like "here is my order, create one".
• PUT or PATCH: change data, like "update the address on this order".
• DELETE: remove data, like "cancel this order".

A response tells the frontend "how it went" through a status code:

• 200: success.
• 400: the request from the frontend is malformed.
• 401 / 403: not logged in, or not allowed to do this.
• 404: this thing cannot be found.
• 500: the backend itself errored, not the frontend's fault.

When you review AI-generated backend code, whether methods and status codes are used correctly is a quick read on quality. Using GET while changing data in the database, or returning 200 for everything (even for errors), are both common problems.

3.A.4 A Minimal Backend Example

Continuing the food-ordering app, here is a Node.js-style route that handles an order:

app.post('/api/orders', function(req, res) {
  const items = req.body.items;
  const total = calculateTotal(items);
  saveOrderToDatabase(items, total);
  res.status(200).json({ message: '订单已收到', total: total });
});

Line by line:

• app.post('/api/orders', ...): a route that handles POST requests sent to the /api/orders path.
• req.body.items: req is the request, req.body is the data the frontend sent, and here it reads the list of items in the order.
• calculateTotal(items): the backend recalculates the total from the item list itself, rather than using the number the frontend sent.
• saveOrderToDatabase(items, total): writes the order into the database.
• res.status(200).json({...}): res is the response, sending back status 200 and some JSON data.

This code walks through the five stages in the diagram above: request comes in, route match, business logic (recalculating), write to database, send the response back.

app.post('/api/orders', function(req, res) {
  const items = req.body.items;
  const total = req.body.total;
  saveOrderToDatabase(items, total);
  res.status(200).json({ message: '订单已收到' });
});

3.B.1 What An API Is

An API (Application Programming Interface) is the backend's instruction sheet for the frontend: it says which features are available, what data to send for each, and what data comes back.

A frontend engineer does not need to know how the backend queries the database or works out the total. They just send and receive data according to this sheet. This division is also why frontend and backend can be built separately: once the API spec is agreed, each side implements its own part and they connect at the end.

3.B.2 REST: A Style For Designing API URLs

REST is the most common style for designing an API. The core idea: treat everything in the system as a "resource", give each resource its own URL, and use the HTTP method to say what action to take on it.

Using the food-ordering app:

The rule: the URL only describes which resource it is (orders, orders/123), the action is expressed by the HTTP method, and no verb appears in the URL.

3.B.3 Common Traps: Verbs In The URL, Wrong Method

AI-generated API design easily comes out like this:

GET /api/getAllOrders
POST /api/createOrder
POST /api/deleteOrder/123

The URLs contain verbs like get, create and delete, repeating what the HTTP method already says. In REST style:

GET /api/orders
POST /api/orders
DELETE /api/orders/123

A more serious trap is using GET to perform an action that changes data, like:

GET /api/deleteOrder?id=123

By HTTP's original design, GET is meant to be "safe", meaning a GET should not change any data on the server, only query it. This is not an optional detail, and there is a real incident behind it. In 2005 Google launched a browser speed-up tool called Web Accelerator that automatically pre-loaded all the links on a page to make browsing faster. Some sites at the time had made "delete" actions into plain links handled with GET. Web Accelerator did not know these links were delete actions and pre-loaded them anyway, and a good number of users had their data wiped by accident. Afterwards, frameworks like Ruby on Rails added protection so developers would not accidentally tie a destructive action to a GET request.

When you review an AI-generated API, watch closely when a GET method is followed by words like "delete" or "update".

3.B.4 The Data Format For Requests And Responses: JSON

The most common format for data passed between frontend and backend is JSON (JavaScript Object Notation). One order in JSON looks roughly like this:

{
  "orderId": 123,
  "items": [
    { "name": "炒饭", "price": 8, "quantity": 2 },
    { "name": "奶茶", "price": 4, "quantity": 1 }
  ],
  "total": 20,
  "status": "confirmed"
}

A few basic rules:

• Data is paired as "key": value, and the key must be wrapped in double quotes.
• A value can be a string ("confirmed"), a number (20), an array (the list wrapped in square brackets under items), or another object (each entry in the items array is an object wrapped in braces).
• Arrays and objects can nest inside each other, as here where items is an array and each element is an object.

This JSON is the req.body from Module 2.C. The frontend wraps it up and sends it, and the backend reads the pieces out with code like req.body.items and req.body.total.

GET  /api/getMenu
GET  /api/getOrder?id=123
POST /api/newOrder
GET  /api/cancelOrder?id=123

GET    /api/menu
GET    /api/orders/123
POST   /api/orders
DELETE /api/orders/123

3.C.1 What A Database Solves

When the backend processes a request, the data usually sits in memory first. The trouble with memory is that the moment the program restarts or the server shuts down, everything in it is gone.

Without a database, one server restart and every order record in the food-ordering app disappears. A database stores data permanently, so no matter how many times the program restarts, the data is still there. This is the core reason a database exists: persistence.

3.C.2 Relational Vs Non-relational Databases

Databases split roughly into two types:

• Relational (PostgreSQL, MySQL): data is stored in tables, much like Excel. Each table has fixed columns, and tables can reference each other through "relationships".
• Non-relational (MongoDB, Redis): data is stored more freely, without every record looking identical, which suits data whose shape changes often.

Most systems that need to record clearly "who relates to whom", like an order system or a membership system, choose a relational database, because relational queries are its strength. This course focuses on relational databases from here.

3.C.3 Tables, Columns, Primary Keys, Foreign Keys

The diagram above is part of the food-ordering app's database design: an orders table stores the orders themselves, and an order_items table stores the items in each order.

A few key ideas:

• Primary key (marked PK): the unique identifier for each row. The id in the orders table and the id in the order_items table are each a unique number within their own table.
• Foreign key (marked FK): the order_id in the order_items table points to the id in the orders table, to say "which order this item belongs to". This is where the word "relational" comes from: foreign keys tie data across tables together.
• One order can have many items. This "one to many" relationship is shown on the diagram as ||--o{.

Why not just stuff the items into one column of the orders table? Because an order might have 1 item or 10, and a table's number of columns is fixed, so it cannot flexibly hold a variable number of things. Splitting into two tables linked by a foreign key is what handles this "one to many" case.

3.C.4 Basic SQL Syntax

The language for working with a relational database is SQL. The four most basic actions:

-- 查询
SELECT * FROM orders WHERE id = 123;

-- 新增
INSERT INTO orders (status, total) VALUES ('pending', 20);

-- 更新
UPDATE orders SET status = 'confirmed' WHERE id = 123;

-- 删除
DELETE FROM orders WHERE id = 123;

These four actions are the database-layer version of the GET / POST / PUT / DELETE from Module 3.A. Once an API endpoint receives a request, it often just translates the request into one matching SQL statement to ask the database for data or to change it.

app.get('/api/orders', function(req, res) {
  const status = req.query.status;
  const query = "SELECT * FROM orders WHERE status = '" + status + "'";
  db.execute(query, function(err, results) {
    res.json(results);
  });
});

'; DROP TABLE orders; --

SELECT * FROM orders WHERE status = ''; DROP TABLE orders; --'

const query = "SELECT * FROM orders WHERE status = ?";
db.execute(query, [status], function(err, results) {
  res.json(results);
});

3.D.1 Authentication Vs Authorization: Two Words Often Mixed Up

• Authentication: who you are. The user enters a username and password and the system confirms "this really is the person", that is authentication.
• Authorization: what you can do. After authentication passes, the system still needs to know whether this person is a regular member or an admin, what they can see and what they can do. That is authorization.

The order is always authenticate first, then authorize. A common bug is doing only authentication and forgetting authorization: the system confirms "this is the person" but never checks "does this person have permission to do this", so any logged-in user, whatever their role, can use features only an admin should touch.

3.D.2 How Passwords Are Stored

Passwords must never be stored in the database as plain text. The reason is direct: once the database leaks, plain-text passwords go straight to the attacker, and since many people reuse one password across sites, a single leak can affect the user's accounts elsewhere too.

The right way is hashing: run the password through a one-way function to get a string that looks like gibberish, and store that gibberish in the database, not the original password. One-way means that even with the gibberish, there is no way to work back to the original password.

Hashing alone is not enough; you also add salt: hash each password together with a randomly generated value, so that even two users with the exact same password end up with different hashes in the database. This stops an attacker from pre-computing a list of "common passwords and their hashes" (called a rainbow table) and matching it against the database to crack it directly.

In practice you do not hand-roll this logic. You use a ready-made library, most commonly bcrypt:

const bcrypt = require('bcrypt');

// 注册时，把密码哈希过再存
const hashedPassword = await bcrypt.hash(password, 10);
db.createUser(username, hashedPassword);

bcrypt handles salting automatically. The 10 is the work factor: a bigger number is harder to brute-force but also slower.

3.D.3 Session And Token: How The Server "Remembers" Who You Are

HTTP itself is stateless, meaning every request is independent and the server does not remember by default who sent the previous one. After a user logs in, every request that follows needs a way to prove "this is still the person who just logged in".

Two common solutions:

• Session: after a successful login, the backend keeps a record on its own side that "this person is logged in", and gives the user a cookie as their identity token. On each later request the browser sends the cookie automatically, and the backend matches it against the record it holds.
• Token (a common implementation is JWT): after a successful login, the backend packs the identity info into an encrypted string and hands it to the user to keep, storing no record on its own side. On each later request the user brings the string to prove their identity, and as long as the backend can verify the string has not been tampered with, it trusts it.

The diagram above shows the token version. The two approaches each have trade-offs, but the core idea is the same: the act of logging in earns you a token you can reuse to prove your identity again and again.

3.D.4 The Security Problems So Far, Seen Together

By this point the course has walked through several security problems, and seeing them together makes it clearer they are the same attitude in different forms: trust nothing that comes from outside, and skip none of the checks you should do.

• A key hard-coded into the code instead of put in an environment variable.
• The backend trusting the total the frontend sends instead of recalculating.
• Using GET to perform a delete that changes data.
• Joining SQL as a string instead of using a parameterized query.
• Passwords stored in plain text instead of hashed.

When you review AI-generated code, these five make a simple checklist.

app.post('/api/login', function(req, res) {
  const { username, password } = req.body;
  const user = db.findUser(username);
  if (user.password === password) {
    res.json({ message: '登入成功' });
  } else {
    res.status(401).json({ message: '密码错误' });
  }
});

const bcrypt = require('bcrypt');

app.post('/api/login', async function(req, res) {
  const { username, password } = req.body;
  const user = db.findUser(username);
  const match = await bcrypt.compare(password, user.password);
  if (match) {
    res.json({ message: '登入成功' });
  } else {
    res.status(401).json({ message: '密码错误' });
  }
});

This is the last unit of Module 3, tying API design, databases and auth into a small backend that actually runs.

3.E.1 How A Backend Project Is Usually Split Into Files

Just like Module 2.D split the frontend into HTML/CSS/JS, a backend project usually does not cram all the code into one file:

server.js         主程式，启动服务器
routes/orders.js  订单相关的路由
routes/auth.js    注册、登入相关的路由
db.js             数据库连接设定

Each file does one thing, so when you later change the order logic you go to routes/orders.js, instead of hunting through one file thousands of lines long.

3.E.2 Middleware: Handling "Every Route Needs This Check"

In the examples so far, every feature that requires a login should, in theory, check "is this person logged in". But copy-pasting that check into every route quickly becomes messy and hard to maintain.

Frameworks like Express provide middleware to solve this. Middleware is a layer that sits between "the request comes in" and "the function that actually handles it", where you can do a shared check and only let the request through if it passes:

function requireAuth(req, res, next) {
  const token = req.headers.authorization;
  if (!token) {
    return res.status(401).json({ message: '请先登入' });
  }
  const user = verifyToken(token);
  if (!user) {
    return res.status(401).json({ message: 'token 无效' });
  }
  req.user = user;
  next();
}

next() is the key: if the check passes, call next() to hand the request to the next step; if it fails, return an error response and do not call next(), so the request stops here and does not continue.

To use it, put the function into the route, between the URL and the real handler:

app.get('/api/orders', requireAuth, function(req, res) {
  db.execute("SELECT * FROM orders WHERE user_id = ?", [req.user.id]);
});

Any route that requires a login just adds requireAuth at the front, with no repeated check logic.

3.E.3 A Full Example: The Backend Of The Food-ordering App

Tying together everything from the earlier units:

const express = require('express');
const bcrypt = require('bcrypt');
const app = express();

// 注册
app.post('/api/register', async function(req, res) {
  const { username, password } = req.body;
  const hashedPassword = await bcrypt.hash(password, 10);
  db.execute(
    "INSERT INTO users (username, password) VALUES (?, ?)",
    [username, hashedPassword]
  );
  res.status(200).json({ message: '注册成功' });
});

// 登入
app.post('/api/login', async function(req, res) {
  const { username, password } = req.body;
  const results = await db.execute(
    "SELECT * FROM users WHERE username = ?",
    [username]
  );
  const user = results[0];
  if (!user) {
    return res.status(401).json({ message: '帐号或密码错误' });
  }
  const match = await bcrypt.compare(password, user.password);
  if (!match) {
    return res.status(401).json({ message: '帐号或密码错误' });
  }
  const token = generateToken(user);
  res.status(200).json({ token: token });
});

// 建立订单，需要登入
app.post('/api/orders', requireAuth, async function(req, res) {
  const items = req.body.items;
  const total = calculateTotal(items);
  await db.execute(
    "INSERT INTO orders (user_id, status, total) VALUES (?, ?, ?)",
    [req.user.id, 'pending', total]
  );
  res.status(200).json({ message: '订单已建立', total: total });
});

Checking through, this code meets every requirement from the earlier units:

• Passwords stored with bcrypt.hash and verified with bcrypt.compare, no plain text in the database (3.D).
• The create-order route has requireAuth, so you cannot use it without logging in (3.D).
• Every query uses ? parameters, no string joining (3.C).
• The total is worked out by the backend with calculateTotal(items), not trusting the frontend's number (3.A).
• URLs and methods follow REST style, POST /api/orders rather than POST /api/createOrder (3.B).

app.post('/api/orders', function(req, res) {
  const items = req.body.items;
  const total = req.body.total;
  const query = "INSERT INTO orders (user_id, total) VALUES (" + req.user.id + ", " + total + ")";
  db.execute(query);
  res.status(200).json({ message: '订单已建立' });
});

Module 3 Recap

The backend module walked through five units. The checklist you now have for reviewing backend code:

• Are the request method and status code used correctly (3.A)?
• Does the API URL follow REST style, and is GET ever used for a destructive action (3.B)?
• Do database queries use parameters instead of string joining (3.C)?
• Are passwords hashed before storing, and do login-only routes have auth (3.D)?
• Does the backend recalculate the key numbers itself, instead of taking the frontend's at face value (3.A, 3.E)?

Module 4 starts on the modern tech stack: how common frameworks and tools combine.