832402209黄浩罡— First Assignment — Front-End and Back-End Separation Calculator System

Web Calculator System – Development Report

Content of Table

1. Project Introduction
2. Project Links
3. PSP Table
4. System Design
5. Main Functions
6. Key Code Implementation
   • 6.1 Frontend API Request
   • 6.2 Backend API
     • 6.2.1 Backend Calculation API (server.js)
     • 6.2.2 Expression Parsing (Recursive Descent)
   • 6.3 Database
     • 6.3.1 Database Operations (database.js)
7. Testing
8. GitHub and Version Control
9. Deployment
10. Problems and Solutions
11. Project Results
12. Personal Reflection
13. Future Improvements

Course Information

1. Project Introduction

This project is a web-based calculator developed using a frontend-backend separated architecture.
The frontend is implemented with HTML, CSS, and JavaScript. The backend is implemented with Node.js, and SQLite is used to store calculation history.
The main functions include:
• Basic arithmetic operations
• Compound expressions
• Parentheses and operator precedence
• Decimal calculations
• Unary operations
• Percentage calculations
• Calculation history
• Deleting and clearing history
• Error handling
The final system was deployed online using Render.

2. Project Links

The following links provide access to the source code, coding standards, and deployed services of the project.

3. PSP Table

PSP (Personal Software Process) was used to estimate and record the time spent on each stage of the project. The estimated total development time was 440 minutes, while the actual development time was 550 minutes.

4. System Design

The project uses a frontend-backend separated architecture.

Figure: System architecture diagram (frontend-backend separated architecture)
The frontend is responsible for the user interface and user interaction.
The backend is responsible for calculation processing, API services, and database operations.
SQLite stores the calculation history.

5. Main Functions

The main functions of the calculator are:

Figure: Functional structure diagram of the calculator
The history module supports:
• Viewing calculation history
• Deleting one record
• Clearing all records

6. Key Code Implementation

6.1 Frontend API Request

The frontend communicates with the backend through HTTP requests.

The frontend communicates with the deployed backend through an HTTP POST request. The API base URL points to the online backend service deployed on Render.

const API_BASE = "https://calculator-backend-code-1.onrender.com";

async function callApi(path, body) {
    const res = await fetch(API_BASE + path, {
        method: "POST",
        headers: {
            "Content-Type": "application/json"
        },
        body: JSON.stringify(body)
    });

    return res.json();
}

This function provides a unified way for the frontend to call backend APIs.

6.2 Backend API

The backend provides APIs for calculation and history management.
Main endpoints include:
| Method | Endpoint | Function |
|---|---|---|
| POST | /api/calculate | Calculate expression |
| POST | /api/unary | Unary operation |
| POST | /api/percent | Percentage calculation |
| GET | /api/history | Get history |
| DELETE | /api/history/{id} | Delete one record |
| DELETE | /api/history | Clear history |

6.2.1 Backend Calculation API (server.js)

The /api/calculate endpoint reads the JSON body, trims the expression, and delegates the calculation to calculateExpression() in the parser module. On success it returns a unified { success, expression, result } payload and automatically saves the record into SQLite; on a parsing error it responds with HTTP 400 and a user-readable message.

// POST /api/calculate - core: parse the expression, calculate, and save it to history
if (req.method === 'POST' && url === '/api/calculate') {
  const body = await readBody(req);
  const expression = String(body.expression || '').trim();

  if (!expression) {
 return sendJson(res, 400, {
   success: false,
   message: 'Invalid expression: empty input'
 });
  }

  const result = calculateExpression(expression);
  return okResult(res, expression, result, expression);
}

/** Success response for calculation APIs; automatically saves the record to the database */
async function okResult(res, expression, result, displayExpression) {
  const payload = {
 success: true,
 expression: displayExpression || expression,
 result: String(result)
  };

  try {
 await db.insertHistory(payload.expression, payload.result);
  } catch (e) {
 // A history write failure does not affect the calculation result
  }

  sendJson(res, 200, payload);
}

function sendCalcError(res, e) {
  if (e instanceof ExpressionError) {
 sendJson(res, 400, {
   success: false,
   message: e.message
 });
  } else {
 sendJson(res, 500, {
   success: false,
   message: 'Internal server error'
 });
  }
}

All responses share one JSON shape, so the frontend only needs a single handler. The backend never evaluates user input: calculation runs in a pure parser, and history is written only after the result is ready.

6.2.2 Expression Parsing (Recursive Descent)

The parser is the core of the backend. The expression is first normalized (× and ÷ become * and /), then tokenize() splits it into numbers and operators, and finally a recursive-descent parser builds and evaluates the syntax tree.

/** Normalize characters: × * -> multiply, ÷ / -> divide (spaces are skipped by the tokenizer) */
function normalize(expr) {
  let out = '';
  for (const ch of String(expr)) {
    if (ch === '×' || ch === '*') out += '*';
    else if (ch === '÷' || ch === '/') out += '/';
    else out += ch;
  }
  return out;
}

/**
 * Grammar:
 *   expression := term { ('+' | '-') term }
 *   term       := factor { ('*' | '/') factor }
 *   factor     := ('+' | '-') factor | primary
 *   primary    := NUMBER | '(' expression ')'
 */

function parseAddSub(tokens, pos) {
  let { node, pos: next } = parseMulDiv(tokens, pos);
  while (tokens[next].type === TOKEN.PLUS || tokens[next].type === TOKEN.MINUS) {
    const op = tokens[next].type === TOKEN.PLUS ? '+' : '-';
    next++;
    const rhs = parseMulDiv(tokens, next);
    node = { op, left: node, right: rhs.node };
    next = rhs.pos;
  }
  return { node, pos: next };
}

function parseMulDiv(tokens, pos) {
  let { node, pos: next } = parseUnary(tokens, pos);
  while (tokens[next].type === TOKEN.MUL || tokens[next].type === TOKEN.DIV) {
    const op = tokens[next].type === TOKEN.MUL ? '*' : '/';
    next++;
    const rhs = parseUnary(tokens, next);
    node = { op, left: node, right: rhs.node };
    next = rhs.pos;
  }
  return { node, pos: next };
}

function parseUnary(tokens, pos) {
  const t = tokens[pos];
  if (t.type === TOKEN.PLUS || t.type === TOKEN.MINUS) {
    const op = t.type === TOKEN.PLUS ? '+' : '-';
    const inner = parseUnary(tokens, pos + 1);
    return { node: { op, unary: true, child: inner.node }, pos: inner.pos };
  }
  return parsePrimary(tokens, pos);
}

/** Evaluate the syntax tree */
function evaluate(node) {
  if (node.value !== undefined) return node.value;

  if (node.unary) {
    const v = evaluate(node.child);
    return node.op === '-' ? -v : v;
  }

  const l = evaluate(node.left);
  const r = evaluate(node.right);

  switch (node.op) {
    case '+': return l + r;
    case '-': return l - r;
    case '*': return l * r;
    case '/':
      if (r === 0) throw new ExpressionError('Division by zero');
      return l / r;
    default:
      throw new ExpressionError('Invalid expression: unsupported operator');
  }
}

Each grammar level maps to one precedence tier: parseAddSub calls parseMulDiv, which calls parseUnary, so multiplication/division bind tighter than addition/subtraction, parentheses group a sub-expression, and a minus in front of a number is a unary sign. Division by zero and malformed input throw ExpressionError, which the API maps to a 400 response. Because the evaluator only walks the parsed tree, eval/exec are never used, which makes code injection impossible.

6.3 Database

SQLite is used to store calculation history.
Each record contains:
• ID
• Expression
• Result
• Creation time
Example:
{
"id": 49,
"expression": "(1+2)*3",
"result": "9",
"created_at": "2026-10-07 13:13:34"
}

6.3.1 Database Operations (database.js)

The project uses sql.js — the SQLite engine compiled to WebAssembly — so no database server needs to be installed, and the database file data/calculator.db persists across restarts.

db.run(
  'CREATE TABLE IF NOT EXISTS calculation_history (' +
    'id INTEGER PRIMARY KEY AUTOINCREMENT, ' +
    'expression TEXT NOT NULL, ' +
    'result TEXT NOT NULL, ' +
    'created_at TEXT NOT NULL' +
  ')'
);

/** Current time, format: year-month-day hour:minute:second */
function nowStr() {
  const d = new Date();
  const p = (n) => String(n).padStart(2, '0');
  return `${d.getFullYear()}-${p(d.getMonth() + 1)}-${p(d.getDate())} ${p(d.getHours())}:${p(d.getMinutes())}:${p(d.getSeconds())}`;
}

/** Insert a history record, returns { id, expression, result, created_at } */
async function insertHistory(expression, result) {
  await init();
  const time = nowStr();

  db.run(
    'INSERT INTO calculation_history (expression, result, created_at) VALUES (?, ?, ?)',
    [String(expression).slice(0, 300), String(result).slice(0, 100), time]
  );

  const rows = db.exec('SELECT last_insert_rowid() AS id');
  const id = rows[0].values[0][0];

  persist();

  return {
    id,
    expression: String(expression).slice(0, 300),
    result: String(result).slice(0, 100),
    created_at: time
  };
}

/** Get all history (ordered by time descending, newest first) */
async function getAllHistory() {
  await init();

  const rows = db.exec(
    'SELECT id, expression, result, created_at FROM calculation_history ORDER BY id DESC'
  );

  if (rows.length === 0) return [];

  const cols = rows[0].columns;

  return rows[0].values.map((v) => {
    const obj = {};
    cols.forEach((c, i) => {
      obj[c] = v[i];
    });
    return obj;
  });
}

/** Delete a history record, returns whether deletion succeeded */
async function deleteHistory(id) {
  await init();

  const n = Number(id);
  if (!Number.isInteger(n) || n <= 0) return false;

  db.run(
    'DELETE FROM calculation_history WHERE id = ?',
    [n]
  );

  const changes = db.getRowsModified();

  persist();

  return changes > 0;
}

All parameters are bound with ? placeholders, so SQL injection is impossible. Every record stores the full timestamp (year-month-day hour:minute:second) required by the assignment, and getAllHistory() orders by id DESC so the newest calculation appears first.

7. Testing

Several functions were tested during development.

Figure 1: 1+2

Figure 2: 1+2*3

Figure 3: (1+2)*3

Figure 4: (1*3)/4

Figure 5: Unary operation

Figure 6: Percentage

Figure 7: Calculation history

Figure 8: Delete history

Figure 9: Clear history

Figure 10: Division by zero

Figure 11: √(9)

Figure 12: 1.1+3

8. GitHub and Version Control

Git was used for version control during development.
The frontend and backend were stored in separate GitHub repositories.
The development process was:
Modify Code
↓
git add
↓
git commit
↓
git push
↓
GitHub
This allowed the source code to be managed and updated systematically.
Frontend GitHub Repository

Backend GitHub Repository

9. Deployment

The application was deployed using Render.
The backend uses the following configuration:
Runtime: Node
Branch: main
Build Command: npm install
Start Command: npm start
The frontend was deployed as a Static Site.
After deployment, the frontend communicates with the public backend API instead of the local localhost address.
Local Development:

Frontend → localhost:3000

After Deployment:

Frontend → Public Backend API

Backend Render Settings

Frontend Render Settings

10. Problems and Solutions

Problem 1: Frontend Could Not Connect to Backend
During local development, the frontend used the local backend address.
After deployment, localhost could no longer be used to access the public backend.
Solution
I changed the frontend API configuration to use the deployed backend URL.

Problem 2: Backend Root Page Error
After deploying the backend separately, opening the backend root page returned an error because the backend was no longer running together with the frontend files.
However, the API endpoints worked correctly.
Solution
The frontend and backend were treated as two independent services, and the frontend communicated with the backend through its API endpoints.

Problem 3: Slow First Request
The deployed application sometimes had a delay when making the first request.
This was related to the behavior of the free cloud hosting environment, where inactive services may need to start again.

11. Project Results

The final calculator can successfully perform calculations and manage calculation history.
The main workflow is:

flowchart TD
    A[User Input] --> B[Frontend]
    B --> C[Backend API]
    C --> D[Calculation]
    D --> E[SQLite]
    E --> F[Result]
    F --> G[Frontend Display]

The application was successfully deployed and tested online.

12. Personal Reflection

This project helped me understand the complete development process of a web application.
I learned how to build a frontend interface, develop backend APIs, use SQLite for data storage, and connect the frontend and backend through HTTP requests.
I also learned that local development and online deployment can involve different problems. For example, the frontend cannot use localhost to access a backend deployed on a public server.
Using Git and GitHub also helped me understand the importance of version control.
Overall, this project improved my practical programming and debugging skills and gave me a better understanding of frontend-backend architecture and cloud deployment.

13. Future Improvements

In the future, the project could be improved by adding:
• More mathematical functions
• A better mobile interface
• Dark mode
• User accounts
• Individual user calculation history
• A more powerful database
• Better deployment performance