Web Application Foundations and Project Orientation

Introduction

Web applications are software systems delivered through a network and accessed primarily with a web browser. They support activities ranging from online banking and learning management to retail, communication, booking, and public services. Unlike a traditional desktop program, a web application commonly separates the user interface, application processing, data storage, and deployment infrastructure across multiple components.

For a full-stack programmer, understanding this structure is more important than memorising a particular programming language or framework. Frameworks change frequently, but the underlying ideas—client–server communication, HTTP requests, APIs, data persistence, authentication, testing, deployment, and maintenance—remain central to professional practice.

This chapter establishes the foundation for the mini-project that will be developed during the programme. It explains how a request travels from a browser to a server and back, introduces the major technologies in a web stack, and presents a disciplined project life cycle. It concludes by defining a feasible scope for an illustrative mini-project.

Learning Objectives

After studying this chapter, you should be able to:

• describe the principal components of a web application architecture;
• explain client–server interaction and the role of HTTP;
• distinguish browsers, web servers, application servers, APIs, and databases;
• explain the functions of domains, DNS, hosting, and development environments;
• distinguish front-end, back-end, and full-stack responsibilities;
• outline the life cycle of a full-stack project;
• identify security, accessibility, privacy, and maintainability concerns; and
• define a realistic scope for a small web application.

1. The Web as a Distributed System

A web application is a distributed system because its components may execute on different computers and communicate over a network. A user may interact with a browser on a laptop, while the application logic runs on a cloud server and the database runs on a separate managed service. Communication is therefore subject to network delay, disconnection, incorrect input, security threats, and differences between devices.

The basic interaction is a request–response cycle:

1. A user performs an action, such as opening a page or submitting a form.
2. The browser creates an HTTP request.
3. The request is routed to a server using domain and network addressing systems.
4. The server interprets the request and may execute application logic.
5. The application may read or write data in a database or call another API.
6. The server returns an HTTP response.
7. The browser interprets the response and presents the result.

This sequence may be repeated many times on one page. A modern interface may initially load HTML, CSS, and JavaScript, then use additional API requests to obtain data without fully reloading the page.

Figure: A simplified web application architecture. The server mediates between the browser and persistent data.

2. Client, Server, and the Application Stack

The client

The client is the software that initiates communication and presents results to the user. In web development, the principal client is a browser such as Chrome, Firefox, Safari, or Edge. The browser performs several tasks:

• resolves and connects to a web address;
• sends HTTP requests;
• interprets HTML to form a document structure;
• applies CSS to control presentation;
• executes JavaScript for interaction and dynamic behaviour;
• stores selected local data, such as cookies; and
• enforces important security rules, including the same-origin policy.

The front end is the part of the application that runs in the client. Its quality is judged not only by appearance but also by usability, accessibility, responsiveness, performance, and correctness.

The server

A server is a computer or software process that responds to requests. A web server such as Nginx or Apache can deliver static files and forward dynamic requests. An application server, often built with Node.js, Python, Java, PHP, C#, or another platform, executes business rules and produces responses.

The back end normally handles routing, validation, authentication, authorisation, data processing, error handling, logging, and integration with databases or external services. A server must treat every client-provided value as untrusted. Client-side validation improves user experience, but server-side validation is essential because a malicious or modified client can bypass browser controls.

The database

A database provides organised, persistent storage. Relational databases such as PostgreSQL and MySQL represent information in tables connected by relationships. A document database such as MongoDB stores records in document-oriented structures. The choice depends on data relationships, transaction requirements, operational constraints, and team expertise.

A database is not merely a file cabinet. It provides mechanisms for querying, indexing, concurrency control, constraints, backup, recovery, and access control. Data design should identify entities, attributes, relationships, required fields, and rules such as uniqueness. For example, a task-management system might contain users, projects, and tasks, with each task belonging to one project and being assigned to an optional user.

The full stack

“Full stack” refers to work across the principal layers of a web application. It does not mean that one programmer must be an expert in every specialised discipline. It means that the developer can understand and connect the layers sufficiently to build, test, and maintain a complete feature.

3. HTTP and Web Communication

HTTP, the Hypertext Transfer Protocol, is an application-layer protocol used for communication between clients and servers. It follows a request–response model and is generally stateless: each request contains the information needed to process it, although cookies, tokens, and server-side sessions can provide continuity across requests.

An HTTP request commonly contains a method, a path, headers, and possibly a body. Common methods include:

• GET: retrieve a resource; it should not intentionally change server state.
• POST: submit data or request creation of a subordinate resource.
• PUT: replace a resource representation.
• PATCH: partially update a resource.
• DELETE: request removal of a resource.

A response contains a status code, headers, and usually a body. Status-code families communicate broad outcomes:

The distinction between authentication and authorisation is fundamental. Authentication asks, “Who are you?” Authorisation asks, “What are you permitted to do?” A 401 response generally indicates missing or invalid authentication, while 403 indicates that the identity is known or understood but lacks permission.

HTTPS and transport security

HTTPS is HTTP carried over TLS. TLS encrypts traffic in transit and helps authenticate the server through certificates. HTTPS does not automatically make an application secure: insecure passwords, broken authorisation, injection vulnerabilities, and excessive data exposure remain possible. Nevertheless, production applications should use HTTPS, protect cookies, avoid transmitting secrets in URLs, and apply secure configuration practices.

APIs and JSON

An API, or Application Programming Interface, defines how software components communicate. A web API normally exposes resources or operations through URLs and HTTP methods. REST-style APIs commonly use resource-oriented paths and JSON representations, for example a request to /api/tasks that returns a collection of task objects.

JSON is convenient because it is human-readable and widely supported, but it is not a substitute for a contract. An API specification should state fields, data types, required values, error formats, authentication requirements, and status codes. Consistent naming and predictable errors reduce front-end complexity.

An API may be:

• internal, used only by components within one organisation;
• partner-facing, shared with selected external systems; or
• public, exposed to a broad developer community under defined terms.

Rate limiting, versioning, monitoring, and documentation become increasingly important as an API gains users.

4. Browsers, Domains, DNS, and Hosting

A domain name is a human-readable identifier such as example.org. The Domain Name System (DNS) maps names to network addresses and other service information. When a user enters a domain, the browser and operating system may consult cached information before asking DNS infrastructure for the relevant record.

Common DNS record types include:

• A: maps a name to an IPv4 address;
• AAAA: maps a name to an IPv6 address;
• CNAME: provides an alias to another domain name; and
• MX: identifies mail servers for a domain.

Hosting is the provision of computing resources from which an application can be accessed. Options include shared hosting, virtual private servers, platform-as-a-service products, serverless functions, and managed cloud services. Hosting decisions involve cost, performance, scalability, deployment convenience, data location, support, and security responsibility.

A useful distinction is between the development, testing/staging, and production environments. Development is optimised for rapid change. Staging should resemble production and is used for release verification. Production serves real users and requires stronger controls, monitoring, backups, and change management. Separating environments reduces the risk that experimental code or test data will affect users.

5. The Development Environment

A development environment consists of the tools and configuration used to create software. A typical setup includes:

• a code editor or integrated development environment;
• a programming-language runtime and package manager;
• a local web server and database;
• browser developer tools;
• Git for version control;
• automated tests and a linter; and
• environment configuration for local services.

Version control records changes and supports collaboration. A sensible workflow uses small commits with meaningful messages, branches or pull requests for review, and a repository that excludes secrets and unnecessary generated files. Configuration that differs between environments should be supplied through environment variables or a secure configuration service rather than hard-coded passwords.

A developer should be able to reproduce the project setup from documented instructions. This is a professional requirement: if the application runs only on its original author’s computer, it is not maintainable.

6. The Full-Stack Project Life Cycle

A mini-project should be managed as a sequence of connected decisions rather than as unplanned coding.

6.1 Problem discovery and stakeholder analysis

Begin with the problem, not the framework. Identify who experiences the problem, what they currently do, what is inefficient or risky, and what outcome would represent improvement. Stakeholders may include end users, administrators, clients, maintainers, and data-protection officers.

6.2 Requirements and acceptance criteria

Functional requirements state what the system should do. Non-functional requirements address qualities such as performance, accessibility, reliability, security, and maintainability. A requirement should be testable. “The system should be easy to use” is too vague; “a user can create a task using keyboard input and receives a visible confirmation” is more verifiable.

Acceptance criteria define conditions under which a feature is considered complete. They should cover successful and unsuccessful cases, including invalid input and unauthorised access.

6.3 Feasibility and scope

Scope is a boundary around the work. A feasible diploma project should have a small number of user roles, a manageable data model, clear workflows, and limited external integrations. A minimum viable product (MVP) contains the smallest set of capabilities that delivers the central value and can be demonstrated reliably.

A useful prioritisation model is:

• Must have: essential for the application’s purpose;
• Should have: valuable but not essential for the first release;
• Could have: desirable if time permits; and
• Won’t have now: deliberately excluded from the current version.

Exclusion is not failure. It is evidence of project control.

6.4 Analysis and design

Design translates requirements into models and interfaces. Important artefacts may include user stories, use-case descriptions, wireframes, entity–relationship diagrams, route specifications, and a component plan.

A user story expresses value from a user perspective, such as: “As a registered student, I want to record a study task so that I can monitor my progress.” It should be accompanied by acceptance criteria.

Database design should avoid unnecessary duplication and should preserve data integrity. API design should define resources, methods, request bodies, responses, validation rules, and errors before front-end and back-end work become tightly coupled.

6.5 Implementation

Implementation is best performed in vertical slices. Instead of completing every screen first and the database last, implement a small end-to-end feature: interface, API route, validation, persistence, and feedback. This reveals integration problems early.

Use readable names, modular functions, consistent formatting, and comments for decisions that are not obvious from the code. Avoid premature abstraction: reusable code is valuable when a genuine repeated pattern exists, but excessive abstraction can conceal simple behaviour.

6.6 Testing

Testing should occur throughout development. Unit tests examine small functions; integration tests examine interactions among components; end-to-end tests simulate user journeys. Manual exploratory testing remains useful for visual and usability issues.

A practical test set includes:

• valid and invalid form input;
• empty, unusually long, and unexpected values;
• unauthenticated and unauthorised requests;
• database failure or unavailable external service;
• different screen sizes and keyboard-only operation; and
• browser console and network errors.

6.7 Deployment and maintenance

Deployment moves a tested version into a hosted environment. A release plan should identify configuration, database migration, domain and HTTPS setup, rollback options, and monitoring. Maintenance includes correcting defects, updating dependencies, improving performance, responding to security events, and adapting to changed requirements.

7. Illustrative Case Study: StudyTrack

The following is a fictional illustrative case designed for a diploma mini-project.

Background and problem

A small training centre currently records student study tasks in paper notebooks and informal messaging groups. Students forget deadlines, tutors cannot easily see general progress, and duplicated communication is common. The centre wants a simple browser-based application called StudyTrack.

Users and requirements

StudyTrack has two initial roles:

• Student: creates, views, edits, completes, and deletes personal study tasks.
• Tutor: views a summary of assigned students’ task completion, but cannot alter a student’s tasks without explicit permission.

The MVP requirements are:

1. users can register and sign in;
2. students can create a task with a title, description, due date, and status;
3. students can filter tasks by status;
4. tutors can view a read-only progress summary; and
5. invalid input produces understandable feedback.

The project will not initially include chat, mobile applications, calendar synchronisation, automated recommendations, payment processing, or real-time notifications. These are future possibilities, not MVP requirements.

Analysis and design

A simple relational model may contain users, tasks, and a relationship in which each task belongs to one student. A task can have statuses such as pending, in_progress, and completed. The database should enforce required fields and valid relationships.

A possible API design is:

The server must ensure that a student cannot access another student’s task merely by changing an identifier in a URL. This is an authorisation check, not just a user-interface concern.

Approach and outcome

The team implements one vertical slice first: sign-in, task creation, database persistence, and task display. They then add editing, filtering, deletion, and the tutor summary. Automated tests cover authentication, task ownership, required fields, and status changes. A staging deployment is used for demonstration before production release.

The expected outcome is not a commercial-scale platform. It is a reliable, documented application that demonstrates a complete flow from browser interface to server logic and database, with evidence of testing and responsible handling of user data.

Learning points

The case illustrates five principles. First, a useful application begins with a real user problem. Second, scope must be limited to protect quality. Third, authorisation must be enforced on the server. Fourth, a full-stack feature is complete only when its layers work together. Fifth, a clear exclusion list is as important as a feature list.

8. Security, Ethics, Accessibility, and Governance

Web applications process information about people, so technical competence must be accompanied by professional responsibility.

Security: Store passwords using a strong, established password-hashing mechanism; never store plain-text passwords. Validate and encode input to reduce injection and cross-site scripting risks. Use parameterised database queries, secure session or token handling, least-privilege access, dependency updates, and useful—but non-revealing—error messages.

Privacy: Collect only information needed for a stated purpose. Explain how data is used, restrict access, retain data only as long as justified, and provide appropriate deletion or correction mechanisms. Legal duties vary by jurisdiction; developers should involve the responsible organisation when personal data is processed.

Accessibility: Interfaces should support keyboard use, readable contrast, meaningful labels, logical focus order, text alternatives where needed, and clear error messages. Accessibility is not an optional visual enhancement; it affects whether people can use the system at all.

Ethics and AI: AI coding assistants can help explain code, generate tests, or suggest alternatives, but their output may contain vulnerabilities, licensing concerns, factual errors, or inappropriate data handling. Developers remain responsible for reviewing, testing, documenting, and securing generated code. Confidential source code and personal data should not be submitted to an AI service without authorisation.

9. Contemporary Developments and Practical Best Practices

Modern applications increasingly use cloud deployment, containers, automated pipelines, managed databases, observability tools, progressive web capabilities, and asynchronous messaging. These technologies can improve delivery, but they also add operational complexity. A diploma project should adopt a technology only when its benefit is clear and its operation can be explained.

Recommended practices include:

1. define the problem and success criteria before selecting tools;
2. keep architecture proportional to project size;
3. document setup, API behaviour, database structure, and known limitations;
4. use version control from the first working file;
5. keep secrets out of source control;
6. validate on both client and server;
7. test ownership and permission boundaries explicitly;
8. design for keyboard access and responsive layouts;
9. back up important data and rehearse recovery where possible; and
10. demonstrate the application using realistic, non-sensitive data.

Chapter Summary

A web application is a distributed system in which a browser communicates with server-side software through HTTP. The front end presents the interface, the back end applies business rules, APIs define communication, and databases provide persistent storage. Domains and DNS make services discoverable, while hosting supplies the infrastructure on which they run. Development environments, version control, testing, staging, and deployment practices make a project reproducible and maintainable.

A disciplined life cycle begins with a user problem and proceeds through requirements, feasibility, design, implementation, testing, deployment, and maintenance. The MVP and prioritisation techniques help a diploma project remain achievable. The StudyTrack case demonstrates how a small but complete system can connect interface, API, authentication, authorisation, and database persistence. Security, privacy, accessibility, ethical AI use, and documentation are integral to professional web development rather than later additions.

Key Terms

API: A defined interface through which software components communicate.

Authentication: Verification of a user or system identity.

Authorisation: Determination of what an authenticated identity is allowed to do.

Back end: Server-side software responsible for application processing and data access.

Browser: Client software that requests, interprets, and displays web resources.

Client: A system component that initiates a request to a service.

Database: Structured software for storing, querying, and managing persistent data.

DNS: The Domain Name System, which maps domain names to network information.

Domain name: A human-readable name used to locate an Internet service.

Front end: The interface and code executed in the user’s browser.

Full stack: The combined presentation, application, data, integration, and infrastructure layers.

HTTP: The protocol used for web request–response communication.

HTTPS: HTTP protected by TLS encryption and server authentication.

MVP: Minimum viable product containing the smallest useful release scope.

Hosting: Provision of computing resources that make an application available.

JSON: A structured text format commonly used for API data exchange.

REST: A resource-oriented style commonly applied to HTTP APIs.

Staging environment: A pre-production environment used for release verification.

TLS: Transport Layer Security, a protocol providing encrypted network communication.

Vertical slice: A feature implemented across the interface, application, and data layers.

Review Questions

Short Answer Questions

1. What is meant by a client–server architecture?
2. Distinguish authentication from authorisation.
3. What is the principal purpose of DNS?
4. Why is server-side validation necessary when client-side validation exists?
5. State two responsibilities of a database in a web application.

Long Answer Questions

1. Explain the HTTP request–response cycle from a user action in a browser to the returned result.
2. Compare the responsibilities of the front end, back end, API layer, and database layer.
3. Describe the major stages of a full-stack project life cycle and explain why each is necessary.
4. Explain how HTTPS improves security and why HTTPS alone does not secure an application.
5. Discuss how scope prioritisation and an MVP can improve the likelihood of completing a diploma mini-project.

Analytical / Application Questions

1. A student can change /api/tasks/15 to /api/tasks/16 and view another student’s task. Identify the security weakness and propose a server-side remedy.
2. Design a feasible MVP for a library-book reservation application. Specify two user roles, four essential features, two exclusions, and three acceptance criteria.
3. A project works locally but fails after deployment because it cannot connect to its database. Analyse three possible causes and describe a systematic debugging approach.

Multiple Choice Questions with Answers

Question 1

Which component is primarily responsible for applying business rules and communicating with a database?

A. Browser

B. Back-end application server

C. DNS resolver

D. CSS stylesheet

Correct Answer: B. Back-end application server

Question 2

Which HTTP method is normally used to retrieve a resource without intentionally changing server state?

A. GET

B. POST

C. DELETE

D. PATCH

Correct Answer: A. GET

Question 3

What does a 403 HTTP response generally indicate?

A. The resource was created successfully

B. The server is unavailable

C. The request lacks permission

D. The domain name was not registered

Correct Answer: C. The request lacks permission

Question 4

Which statement best distinguishes authentication from authorisation?

A. Authentication checks identity; authorisation checks permitted actions

B. Authentication encrypts data; authorisation compresses data

C. Authentication stores records; authorisation creates databases

D. Authentication is performed only by browsers; authorisation only by DNS

Correct Answer: A. Authentication checks identity; authorisation checks permitted actions

Question 5

What is the main purpose of DNS?

A. To style HTML documents

B. To map domain names to network information

C. To hash user passwords

D. To execute JavaScript in a browser

Correct Answer: B. To map domain names to network information

Question 6

Why should an API specification define error formats as well as successful responses?

A. To eliminate the need for a database

B. To make client behaviour predictable when requests fail

C. To prevent all network delays

D. To replace authentication

Correct Answer: B. To make client behaviour predictable when requests fail

Question 7

Which practice best protects against a student accessing another student’s task by changing an identifier in a URL?

A. Hide the identifier with CSS

B. Validate ownership and permissions on the server

C. Disable browser developer tools

D. Use a larger screen layout

Correct Answer: B. Validate ownership and permissions on the server

Question 8

Which environment should most closely resemble production while remaining separate from real users?

A. Development

B. Staging

C. Personal browser cache

D. DNS cache

Correct Answer: B. Staging

Question 9

Which item is most appropriate for an MVP?

A. Every possible future feature

B. The smallest set of capabilities delivering the central user value

C. A complete replacement for all related systems

D. Only a visual mock-up with no working logic

Correct Answer: B. The smallest set of capabilities delivering the central user value

Question 10

Which statement about client-side validation is correct?

A. It removes the need for server-side validation

B. It is useful for user experience but cannot be trusted as the sole security control

C. It is performed by DNS before a request is sent

D. It guarantees that database constraints are satisfied

Correct Answer: B. It is useful for user experience but cannot be trusted as the sole security control