From Stand-alone to Web System: Scope, Architecture and Stack

In Project I your program ran on one computer for one user. In Project II the same idea must run on a server and be used by many people from their own phones and browsers.

That one change brings new problems: networks, shared data, logins, attacks and deployment.

This unit shows what changes, how to describe the new system with an architecture, and how to choose the stack and the REST resources before writing code.

1.1 What changes in Project II

A web system is judged on more than "does it run on my laptop". Five things change.

Because of these five changes, the report for Project II must also contain an architecture, a security chapter and a deployment section.

Examiners often ask "what happens if two people click at the same moment?" and "what stops a stranger from reading all patient records?". This book prepares those answers.

1.2 The running example: ClinicQ

ClinicQ is invented for this book. A community health post in a Nepali town sees about 150 patients per day. A clerk hands out paper slips as tokens, and the slips are sometimes lost or duplicated.

Problem statement, version 1. "Patients of a 150-patient-per-day health post receive paper token slips.

The average wait is 95 minutes because nobody knows the real queue position, and about 1 token in 12 is duplicated or lost, causing quarrels at the counter. Without change, waiting grows as the catchment population grows."

Objectives (SMART).

Scope table.

Notice objective O2: it is only a problem in a web system. Two requests that arrive together could both read "last number is 7" and both write 8. Section 2.4 shows how a database constraint prevents that.

1.3 Client-server and three-tier architecture

In the client-server model the client asks and the server answers. In a three-tier architecture the server side is split into two layers, so the whole system has three tiers:

1. Presentation tier: HTML, CSS and JavaScript running in the browser, or a mobile app screen.
2. Application (logic) tier: the program on the server that checks input, applies rules (such as "one token per number per day") and builds the reply.
3. Data tier: the database that stores patients and tokens permanently.

The tiers can run on one computer during development and on three machines in a big deployment. The design is the same, and that is its value: you can replace the database or the screens without rewriting the logic.

(a) Rack of servers

(b) Switch and patch panels

(c) Technician at a server

1.4 Choosing the stack

A stack is the set of languages, framework and database you use. Choose by what your team already knows and by what the college server can run, not by fashion.

This book uses the Python standard library so that the mechanics (a socket, a request line, a JSON body, a SQL statement) are visible. Moving to Flask later changes the syntax, not the ideas.

1.5 REST resources and status codes

REST treats everything as a resource with a URL and uses the HTTP verb to say what to do. Names are nouns in the plural; the verb carries the action. The reply code tells the client what happened.

Rules that examiners like: GET never changes data; 401 means "who are you?", 403 means "I know you but you may not"; 422 means "well-formed but not acceptable"; never reply 200 with {"error": ...} inside.

1.6 From requirements to user stories

Write each requirement as a story: As a [role] I want [action] so that [benefit]. Rank them with MoSCoW (Must, Should, Could, Won't now).

1.7 Eight reasons web projects fail, and the cure

1. Only the "happy path" works. The demo runs once with perfect input and fails when the examiner types a blank name. Write the error replies (400, 404, 422) at the same time as the success reply, as in Section 2.3.
2. Passwords stored in plain text. One leaked file exposes every account. Store salted slow hashes (Unit 3) from the first login screen, never "later".
3. Everything in one file. HTML, SQL and rules are mixed, so a small change breaks three things. Keep tiers separate: handlers, rules and database access in different functions.
4. No design of the data. Tables are changed daily and old rows break. Draw the ER diagram first and add constraints (UNIQUE, NOT NULL, FOREIGN KEY) so the database refuses bad data.
5. Works only on the developer's laptop. Paths, ports and passwords are hard-coded. Put settings in environment variables and test a deployment in week 8, not week 12.
6. Ignoring two users at once. Duplicate token numbers appear only under load. Use database constraints and transactions, and test with parallel requests (Unit 4).
7. Copying a tutorial without understanding it. The viva asks "why this status code?" and the answer is silence. Keep a design note for every decision and be able to defend it.
8. No backup and no log. When a bug corrupts data or a stranger logs in, there is no evidence. Back up the database daily and log every login and status change with time and user.

(a) A mobile-network tower, the first hop of every phone client; the client of every web project

(b) Where 340 ms go when a ClinicQ page loads

Formula and fact sheet

• Three tiers: presentation, logic, data. HTTPS is terminated at the proxy.
• Status codes: 200 OK, 201 Created, 400 bad input, 401 not authenticated, 403 forbidden, 404 not found, 422 unprocessable, 429 too many requests, 500 server error.
• MoSCoW: Must, Should, Could, Won't now.
• Problem statement = who + what + how big + what if nothing changes.

Practice

1. List the five concerns that change when a stand-alone project becomes a web project.
2. Write a four-part problem statement for a ward-office appointment system.
3. Name the three tiers of ClinicQ and say what each stores or does.
4. Why can the browser not talk to the database directly?
5. Give the REST URL and method to cancel token 7.
6. Difference between 401 and 403 with an example.
7. Why is POST /api/tokens better than GET /api/newToken?
8. Rank four user stories of a bus-ticket system with MoSCoW.
9. Why does the scope table of ClinicQ place SMS out of scope?
10. A clerk issues 150 tokens a day. At 6 seconds each on paper, how many minutes of clerk time per day? At 1 second each in ClinicQ, how many minutes are saved?

Model answers: medium (5 marks) and long (10 marks) questions

Q1 (5 marks). Explain the three-tier architecture of a web application with a diagram reference and an example.

Introduction. A three-tier architecture splits a web application into three layers that communicate in one direction, so that each can be changed, secured and scaled on its own.

The tiers.

1. Presentation tier. The HTML, CSS and JavaScript in the user's browser or the screens of a mobile app. It collects input and shows results but holds no trusted rules, because the user controls this code.
2. Application tier. The server program (Python, PHP, Java or Node). It authenticates the user, validates input, applies business rules such as "one token number per day" and builds the JSON reply.
3. Data tier. The database (SQLite, MySQL, PostgreSQL) that stores records permanently and enforces constraints.

Example and figure. In Figure 1.1 a patient opens the ClinicQ page; the browser sends GET /api/tokens over HTTPS to the reverse proxy; the proxy forwards it to the API; the API runs a SELECT on the database and returns the queue as JSON.

Why use it. (i) Security: the browser never reaches the database. (ii) Maintainability: the database can change from SQLite to MariaDB without changing the screens. (iii) Scalability: more application servers can be added behind the proxy.

Conclusion. Separating presentation, logic and data is the standard design of web projects, and it gives the examiner a clear map of the system.

Q2 (5 marks). Describe REST and design the resources and status codes for a token-queue service.

Introduction. REST (Representational State Transfer) is a style for designing web APIs in which every thing is a resource with its own URL and the HTTP method states the action.

The server keeps no memory of the client between requests, so every request carries what the server needs.

Design rules. (i) Use plural nouns in URLs, such as /api/tokens. (ii) Use GET to read, POST to create, PUT or PATCH to change, DELETE to remove. (iii) GET must never change data. (iv) Exchange data as JSON. (v) Reply with the correct status code.

Resources for ClinicQ.

Conclusion. A clean REST design lets any client (browser, Android app, another college system) use the same API, and the status codes make failures easy to test.

Q3 (10 marks). Explain how a stand-alone student project is turned into a web system. Cover architecture, data, security, testing and deployment, and give an example.

Introduction. A stand-alone program serves one trusted user on one computer. A web system serves many untrusted users over a network, so the same idea needs extra design in five areas.

The example is ClinicQ, a health-post token queue that grows from a paper slip system into a web service.

1. Architecture. The program is split into three tiers: browser, application server and database (Figure 1.1). A reverse proxy such as Nginx accepts HTTPS and forwards to the application.

Each arrow between tiers is a trust boundary, so each side validates what it receives.

2. Data. The database is shared, so integrity moves from the program into the database. UNIQUE(day, no) guarantees that no two tokens of one day share a number even when two requests arrive together; foreign keys stop a token from pointing at a missing patient; CHECK limits status values.

3. Interface. The server publishes a REST API with nouns for URLs, verbs for actions and status codes for outcomes (Section 1.5). Any client can then use it, and each endpoint can be tested without a browser.

4. Security. Anyone on the internet can send any request, so the system needs login, salted password hashes, signed tokens, input validation, parameterised SQL and HTTPS (Unit 3). Roles decide that a patient may only read the queue while staff may change it.

5. Testing and deployment. Unit tests check rules, API tests check status codes, and a load test checks that 50 parallel requests create 50 distinct numbers (Unit 4).

The service is then deployed on a server with a domain name, HTTPS, environment-variable settings, logs and daily backups.

Conclusion. Turning a program into a web system is mostly about trust, sharing and delivery. A student who can show these five areas, with measured results against the objectives, has met the intent of Project II.