Project II
Semester V · BCA 306 · 3 credits
0 / 5
chapters done
-
The syllabus asks for
- What changes in Project II
- The running example: ClinicQ
- Client-server and three-tier architecture
- Choosing the stack
- REST resources and status codes
- From requirements to user stories
- Eight reasons web projects fail, and the cure
Key points
- A web project adds many users, a network, shared data, untrusted input and deployment to the concerns of Project I.
- ClinicQ is the running example; its objectives are measurable and its scope table lists what is out.
- The three-tier architecture separates the browser, the logic and the database; every arrow between them is a trust boundary.
- REST uses nouns for URLs, verbs for actions and status codes for the outcome.
- Choose the stack for the team's skills; this book uses the Python standard library to show the mechanics.
-
The syllabus asks for
- Designing the data
- What happens when a request arrives
- The ClinicQ API, complete
- Two clerks at the same moment: the race condition
- Transactions and error replies
- Eight reasons to validate and constrain at every layer
Key points
- ClinicQ has two tables, patient and token, in a one-to-many relation with five kinds of constraint.
- A request flows: parse, validate, run SQL, build JSON, reply; invalid input is rejected early.
- The 78-line API replies 201, 400, 404, 422 and 200 and was run over a real local HTTP connection.
- Race conditions are solved by database constraints plus a retry, not by hoping.
- Safe errors tell the client what to fix and hide the internals.
-
The syllabus asks for
- Who are you, and what may you do?
- Passwords: never store them, store a salted slow hash
- Signed tokens: logging in without sending the password again
- SQL injection: the attack and the cure
- Brute force and rate limiting
- The common attacks and their defences
- Eight security practices every student web project needs
Key points
- Authentication and authorisation are different questions with different status codes.
- Passwords are stored as salted slow hashes; the run showed different hashes for one password and a failed check for one changed letter.
- Signed tokens carry user, role and expiry; the run refused edited, expired and malformed tokens.
- Parameterised SQL beats injection; rate limits and long passwords beat brute force.
- Security is layered: HTTPS, login and roles, validation, protected data and logs.
-
The syllabus asks for
- What to test, and in what proportion
- Automated unit tests for the ClinicQ rules
- The test-case table for the report
- Performance: how many users can one server carry?
- Deployment: from your laptop to a URL
- Eight practices that make a project demo-proof
Key points
- Tests are layered; the 9-test suite for ClinicQ rules passed and each test name states a requirement.
- The test-case table with expected and actual results is the evidence the examiner reads.
- Capacity is computed: at peak ClinicQ needs about 4 requests per second, 16 % of one small worker.
- A cache and more workers are the first scaling steps.
- Deployment is a repeatable pipeline with a health check; Nginx handles HTTPS and systemd keeps the service alive.
-
The syllabus asks for
- The report: what goes where
- API documentation that cannot go out of date
- Preparing the 10-minute demo
- Twelve viva questions for a web project
- Eight habits of students who score well
Key points
- The report proves every early claim with evidence in later chapters.
- Generated API documentation and a good README let a stranger use the system.
- A timed demo with a fallback survives load-shedding and network failures.
- Twelve viva questions cover architecture, REST, security, concurrency, testing and deployment.
- Honesty, numbers and shared understanding are what separate good projects from copied ones.
No chapter matches. Try another word.
The paper
TU assessment: 60% final examination set by the university, 40% internal (assignments, lab work, attendance). Confirm the split in your college's notice.