Web Architecture and Development Foundations

Introduction

The modern web is a distributed software platform built on the Internet. It enables a browser running on a user’s device to obtain documents, data, media, and executable programs from computers and services distributed across the world. A React application is therefore not an isolated interface: it participates in a larger system involving networks, name resolution, security protocols, servers, databases, APIs, browsers, and deployment processes.

Understanding this architecture is essential for effective JavaScript and React development. Many apparent front-end problems—slow pages, failed requests, incorrect data, authentication errors, or broken navigation—originate in another layer of the system. This chapter establishes the conceptual foundation required to reason about those layers.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish the Internet from the World Wide Web;
• explain clients, servers, networks, DNS, URLs, and HTTP/HTTPS;
• trace a browser request from entering a URL to rendering a page;
• describe browser rendering and the role of JavaScript and React;
• explain REST principles and identify suitable HTTP methods and status codes;
• use browser developer tools to investigate web applications;
• describe a professional web development lifecycle;
• evaluate performance, security, accessibility, and maintainability concerns.

1. The Internet and the World Wide Web

The Internet is a global interconnection of networks that communicate using the Internet Protocol Suite, commonly called TCP/IP. It includes physical cables, wireless links, routers, switches, data centres, domain-name services, and communication protocols. The Internet supports many applications, including email, file transfer, voice communication, online gaming, and the Web.

The World Wide Web is one application that runs on the Internet. It uses resources identified by URLs and commonly transfers them through HTTP or HTTPS. A web page, image, stylesheet, or API response is a Web resource; the Internet provides the communication infrastructure through which that resource is reached.

This distinction matters. A browser uses the Internet to access the Web, but the Internet itself is broader than web browsing. Similarly, HTTP is an application-layer protocol, whereas IP is responsible for addressing and routing packets between networks.

A layered view

A useful conceptual model separates responsibilities:

These layers are conceptual rather than a complete implementation diagram. For example, HTTP/3 uses QUIC, which runs over UDP, while HTTP/1.1 and HTTP/2 commonly use TCP. The important principle is separation of concerns: an application developer can use HTTP without implementing packet routing.

2. Web Architecture

A conventional web system has several cooperating components:

• User agent: normally a browser such as Chrome, Firefox, Safari, or Edge.
• Client: the program that initiates a request. A browser is a common client, but a mobile application or command-line tool can also be one.
• Web server: accepts network requests and returns files or responses.
• Application server: executes business logic, authentication, validation, and data processing.
• Database: stores structured or unstructured application data.
• Cache and content delivery network (CDN): stores frequently requested content closer to users.
• Reverse proxy or load balancer: receives public traffic and routes it to suitable internal services.

A small site may combine these roles on one machine. A large system may distribute them across many regions and services. Distribution improves scalability and resilience but introduces complexity involving consistency, observability, security, and deployment.

Figure: A simplified web request–response architecture.

3. DNS and URLs

Domain Name System

Computers communicate using IP addresses, but people prefer names such as example.edu. The Domain Name System (DNS) translates domain names into records, commonly including IPv4 A records and IPv6 AAAA records. A browser or operating system may first consult local caches. If no usable answer exists, a recursive resolver queries authoritative DNS servers and returns the result.

DNS is distributed and hierarchical. The root zone delegates to top-level domains such as .com or .edu; authoritative name servers then provide records for a particular domain. DNS caching reduces latency and traffic. The time to live (TTL) indicates how long a response may generally be cached, although operational behaviour also depends on resolver policies.

DNS does not normally deliver the web page itself. It helps a client find an address; HTTP or HTTPS then communicates with the service at that address. A domain may resolve to a CDN, load balancer, or several addresses.

Uniform Resource Locators

A URL identifies the location and access method of a resource. A typical URL is:

https://www.example.com:443/products/item-7?colour=blue#reviews

Its parts are:

Fragments are not sent to the server in the HTTP request; the browser uses them locally, often to navigate to an element or application state. Query parameters are sent and must not be treated as secret merely because they are not in the path.

URL encoding represents characters that have special meanings or cannot safely appear in a URL. Applications should use established URL APIs rather than manually concatenating untrusted strings.

4. HTTP and HTTPS

HTTP is a request–response protocol. A client sends a request containing a method, target, headers, and sometimes a body. The server returns a response containing a status code, headers, and sometimes a body.

A simplified request is:

GET /api/products/7 HTTP/1.1
Host: shop.example
Accept: application/json

A response may be:

HTTP/1.1 200 OK
Content-Type: application/json

{"id":7,"name":"Keyboard"}

HTTP is generally stateless: each request contains the information needed for the server to process it, although cookies, tokens, and server-side sessions can create an application-level notion of continuity.

HTTP methods

A method is safe when it is intended not to change server state. A method is idempotent when repeating the same request has the same intended effect as making it once. Idempotence does not mean that every response is identical; timestamps, logs, or status codes may differ.

Status codes

Status codes communicate broad outcomes:

• 2xx: successful processing, such as 200 OK, 201 Created, and 204 No Content;
• 3xx: redirection or conditional response, such as 301 or 304;
• 4xx: an apparent client-side issue, such as 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, or 429 Too Many Requests;
• 5xx: a server-side failure, such as 500 Internal Server Error or 503 Service Unavailable.

A 401 generally indicates missing or invalid authentication credentials, whereas 403 indicates that the request is understood but not permitted. Exact API conventions should be documented rather than inferred blindly.

HTTPS

HTTPS is HTTP protected by TLS. TLS provides encryption against eavesdropping, integrity protection against undetected alteration, and server authentication through certificates. Certificate validation uses a chain of trust involving certificate authorities and the browser’s trust store.

HTTPS does not make an application automatically secure. It does not prevent SQL injection, insecure access control, malicious scripts, weak passwords, or accidental exposure of sensitive data in logs. Developers must also validate input, protect credentials, configure cookies appropriately, apply authorization, and manage secrets.

5. From URL Entry to Rendered Page

When a user enters a URL, a simplified sequence is:

1. The browser parses the URL and checks caches, service workers, and security policies.
2. DNS resolution obtains an address when needed.
3. The browser establishes a connection. HTTPS additionally performs a TLS handshake and validates the certificate.
4. The browser sends an HTTP request.
5. A proxy, CDN, or server receives the request and may serve cached content.
6. Application code may authenticate the request, query a database, call another service, and construct a response.
7. The browser receives bytes, interprets response headers, and processes the content.
8. HTML is parsed into the DOM; CSS is parsed into the CSSOM; JavaScript may modify both.
9. The browser calculates styles and geometry, paints pixels, and composites layers for display.
10. Additional resources and API requests may be initiated during or after rendering.

Network timing is not one single delay. A useful decomposition is:

Here each T term is a time interval, measured in milliseconds or another consistent unit. The approximation is not an exact universal equation: phases can overlap, DNS can be cached, connections can be reused, and rendering can begin before the complete response arrives. It is useful for diagnosis because different terms suggest different remedies.

Browser rendering

The browser parses HTML into a Document Object Model (DOM) tree. CSS rules form a CSS Object Model, and together they determine computed styles. The browser performs layout, calculating positions and dimensions, then paints text, borders, images, and backgrounds. Compositing combines painted layers for display.

JavaScript runs in the browser’s execution environment. It can respond to events, manipulate the DOM, request data using fetch, and update application state. React provides a component model and a rendering strategy that helps developers describe the interface as a function of state. React does not replace HTTP, DNS, the browser, or the server; it operates primarily within the client-side application layer.

Client-side rendering can produce a minimal HTML shell followed by JavaScript-generated content. Server-side rendering produces initial HTML on the server and may then “hydrate” it so that client-side JavaScript attaches behaviour. Static generation creates HTML during a build. Each approach involves trade-offs among initial performance, interactivity, search indexing, infrastructure cost, and implementation complexity.

6. REST and API Design

Representational State Transfer (REST) is an architectural style, not a particular library or data format. A RESTful design commonly includes:

1. Client–server separation: user-interface concerns and data-service concerns are separated.
2. Stateless communication: each request contains sufficient context for processing.
3. Cacheability: responses indicate whether they may be reused.
4. Uniform interface: resources, representations, and standard operations follow consistent conventions.
5. Layered system: intermediaries may exist without the client needing to know every layer.
6. Code-on-demand: optional; servers may provide executable code to clients.

An API might expose /products/7 as a resource. GET retrieves it, PATCH changes selected fields, and DELETE removes it. A collection such as /products can support GET for listing and POST for creation. Good design uses meaningful representations, consistent errors, validation, pagination for large collections, and explicit authentication and authorization rules.

REST should not be confused with “JSON over HTTP.” JSON is a representation format, while REST describes architectural constraints. An API can use JSON without satisfying all REST constraints, and REST representations need not be JSON.

7. Browser Developer Tools

Developer tools provide evidence about what the browser is doing. Important panels include:

• Elements/Inspector: inspect DOM nodes, computed styles, layout, and accessibility properties;
• Console: view errors, warnings, logs, and JavaScript evaluation results;
• Network: inspect requests, methods, URLs, status codes, headers, payloads, timing, and caching;
• Sources/Debugger: set breakpoints, inspect call stacks, and step through code;
• Application/Storage: inspect cookies, local storage, session storage, caches, and service workers;
• Performance: record rendering, scripting, layout, painting, and long tasks;
• Lighthouse or auditing tools: obtain automated indicators for performance, accessibility, best practices, and search-related concerns.

A disciplined debugging process begins by reproducing the problem and recording its conditions. In the Network panel, check whether a request was sent, whether DNS or connection failed, which status code returned, whether the response has the expected content type, and whether the browser blocked it because of CORS or mixed content. In the Console, read the earliest relevant error rather than the last cascade of symptoms.

Tools are powerful but not authoritative in every context. A request may succeed in a developer session because of cached credentials, while a new user fails. Disable cache, test different network conditions, and verify behaviour in more than one browser where compatibility matters.

8. The Web Development Lifecycle

Professional development is iterative rather than a simple sequence of coding tasks.

Requirements and discovery

The team identifies users, goals, constraints, data needs, security requirements, accessibility expectations, and success measures. Ambiguous requirements are converted into testable acceptance criteria.

Architecture and design

Developers decide how the client, APIs, databases, identity systems, hosting, and external services will interact. Threat modelling, data classification, error handling, and observability should occur before implementation, not after an incident.

Implementation

Code is organized into understandable components and modules. Teams use version control, code review, linting, formatting, automated tests, and dependency management. React components should have clear responsibilities, predictable state flow, and accessible HTML semantics.

Verification

Unit tests examine small functions or components. Integration tests examine interactions among modules and services. End-to-end tests exercise realistic user journeys. Manual exploratory testing remains valuable for visual, accessibility, and unusual failure conditions.

Deployment and operations

A build pipeline produces versioned artifacts and deploys them to environments such as development, staging, and production. Continuous integration validates changes; continuous delivery or deployment automates release processes. Monitoring should include availability, error rates, latency, resource use, and meaningful user outcomes.

Maintenance

Web systems require dependency updates, security patches, accessibility improvements, performance work, content changes, and refactoring. A successful release is not the end of development; it is the beginning of operational learning.

9. Applied Case: University Course Registration Portal

The following is an illustrative case.

Background

A university wants a React-based portal through which students can search courses, inspect prerequisites, and register. The existing system displays course information slowly and sometimes reports that a course is full after registration has already occurred.

Problem analysis

Developer tools reveal that the browser downloads a large JavaScript bundle before displaying any course information. The Network panel shows repeated requests for the same course list. The API returns 200 OK even when a registration fails because the server encodes errors inside a successful response. On the server, two students can be admitted to the final available place because availability is checked separately from the database update.

Approach

The team designs a resource-oriented API:

• GET /courses?term=2026-spring retrieves a paginated course collection;
• GET /courses/{id} retrieves course details;
• POST /registrations requests registration;
• DELETE /registrations/{id} drops a registration.

The API validates authentication and authorization on every protected request. The registration operation performs availability checking and enrollment update within an appropriate transactional database operation. A conflict is represented with a documented error response rather than a misleading success response.

On the client, the team introduces route-level code splitting, accessible loading and error states, request cancellation for obsolete searches, and cache-aware data fetching. The interface uses semantic headings, labels, keyboard-accessible controls, and clear status messages. Automated tests cover prerequisite rejection, duplicate registration, full-course conflict, and successful enrollment.

Outcome

The first course list appears sooner because less code is loaded initially. Repeated searches avoid unnecessary requests when cached data remains valid. Registration conflicts are reported consistently, and the server—not the browser—is responsible for enforcing enrollment rules.

Learning points

The case demonstrates that user experience depends on the complete architecture. React can improve client organization, but it cannot repair a race condition in a database transaction. HTTP status conventions improve communication, but they must be paired with sound business logic. Performance, security, accessibility, and correctness are cross-layer responsibilities.

10. Limitations, Ethics, and Contemporary Practice

Web architecture involves trade-offs. More caching can reduce latency but may expose stale information. Client-side applications can provide rich interaction but may increase initial download size and complicate accessibility. Microservices can enable independent deployment but add network failure modes and operational overhead. Server-side rendering can improve initial content delivery but increases server complexity.

Privacy requires data minimization, clear notices, appropriate consent where legally required, retention controls, and protection against unnecessary tracking. Accessibility is both an ethical obligation and, in many jurisdictions, a legal or regulatory requirement. Interfaces should support keyboard navigation, readable contrast, text alternatives, understandable errors, and assistive technologies.

Security practices include TLS, secure cookie attributes, strong authentication, authorization checks, output encoding, input validation, dependency review, content security policies, rate limiting, and careful secret management. Developers should never place private keys or credentials in client-side bundles; anything delivered to a browser must be considered observable by the user.

Current practice increasingly includes edge delivery, HTTP/2 and HTTP/3, WebAssembly, progressive web applications, observability platforms, automated accessibility testing, and AI-assisted coding. AI tools can accelerate prototyping and explanation, but generated code requires human review for correctness, security, licensing, privacy, accessibility, and maintainability. An assistant may confidently suggest an insecure dependency or incorrect API behaviour; engineering responsibility remains with the development team.

Best-Practice Checklist

• Use semantic HTML before adding JavaScript behaviour.
• Treat all client input as untrusted.
• Use HTTPS and secure credential-handling practices.
• Design APIs with consistent methods, status codes, validation, and errors.
• Measure performance with realistic devices and networks.
• Test loading, empty, error, unauthorized, and offline states.
• Build accessibility into requirements and verification.
• Keep secrets on trusted server-side systems.
• Use version control, code review, automated testing, and reproducible builds.
• Monitor production behaviour and learn from real failures.

Chapter Summary

The Internet is the global network infrastructure, while the Web is an application that uses resources, URLs, and HTTP. DNS translates human-readable domain names into network addresses. A URL identifies a resource through a scheme, host, optional port, path, query, and fragment.

HTTP uses request–response communication with methods, headers, bodies, and status codes. HTTPS adds TLS encryption, integrity, and certificate-based authentication, but application security still requires validation, authorization, safe coding, and privacy controls. A browser resolves a name, establishes a connection, sends a request, receives a response, parses HTML and CSS, executes JavaScript, and renders pixels. React operates mainly in the client layer and should be understood as one part of a broader system.

REST provides architectural constraints for designing networked APIs, including stateless communication, resource-oriented interfaces, cacheability, and client–server separation. Developer tools make network, rendering, storage, and JavaScript behaviour observable. Finally, professional web development includes requirements, architecture, implementation, testing, deployment, monitoring, and continuous maintenance. Reliable web applications result from coordinated attention to performance, security, accessibility, correctness, and user needs.

Key Terms

Internet: Global interconnection of networks using Internet protocols.

World Wide Web: A distributed information system using URLs and web protocols.

Client: Software that initiates a request to a service.

Server: Software or hardware that provides resources or services to clients.

DNS: Distributed system that maps domain names to records such as IP addresses.

URL: Structured identifier specifying how and where a resource can be accessed.

HTTP: Application-layer request–response protocol used by the Web.

HTTPS: HTTP protected by Transport Layer Security.

TLS: Protocol providing encryption, integrity, and authenticated communication.

HTTP method: Standard operation such as GET, POST, PUT, PATCH, or DELETE.

Status code: Numeric indication of an HTTP response outcome.

DOM: Tree representation of a document maintained by the browser.

Rendering: Process of converting document, style, and script results into displayed pixels.

API: Defined interface through which software systems communicate.

REST: Architectural style based on constraints for networked applications.

Cache: Stored copy of data used to reduce repeated retrieval.

CDN: Distributed infrastructure that delivers content from locations near users.

CORS: Browser security mechanism governing cross-origin requests.

Accessibility: Design of technology so people with varied abilities can use it.

Observability: Ability to understand system behaviour through logs, metrics, and traces.

Review Questions

5 Short Answer Questions

1. How does the Internet differ from the World Wide Web?
2. What is the purpose of DNS in a web request?
3. Name the principal components of a URL.
4. What information does an HTTP status code communicate?
5. Why does HTTPS alone not guarantee application security?

5 Long Answer Questions

1. Explain the complete sequence from entering an HTTPS URL to displaying a rendered page.
2. Compare GET, POST, PUT, PATCH, and DELETE, including their intended semantics.
3. Explain the principal REST constraints and discuss why JSON alone does not make an API RESTful.
4. Describe how HTML, CSS, JavaScript, the DOM, layout, painting, and React contribute to rendering.
5. Discuss the stages of the web development lifecycle and explain why monitoring continues after deployment.

3 Analytical / Application Questions

1. A page loads quickly for returning users but slowly for first-time visitors. Use the request timeline to identify possible causes and propose evidence-based tests.
2. Design an API for course registration. Specify suitable resources, methods, status codes, validation rules, and a strategy for preventing two users from claiming the same final place.
3. A React application works locally but fails in production with unauthorized API requests and browser CORS errors. Develop a systematic investigation plan using developer tools and explain the security implications.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes the Internet from the World Wide Web?

A. The Internet is a web browser, while the Web is a database.

B. The Internet is network infrastructure, while the Web is an application using it.

C. The Internet only supports email, while the Web only supports video.

D. The Internet and the Web are exactly the same system.

Correct Answer: B. The Internet is network infrastructure, while the Web is an application using it.

Question 2

What is the primary role of DNS?

A. To encrypt HTTP response bodies

B. To render HTML as pixels

C. To translate domain names into records such as IP addresses

D. To store application passwords

Correct Answer: C. To translate domain names into records such as IP addresses

Question 3

Which URL component is generally not sent to the server in an HTTP request?

A. Host

B. Path

C. Query

D. Fragment

Correct Answer: D. Fragment

Question 4

Which HTTP method is normally used to retrieve a representation without intending to change server state?

A. GET

B. POST

C. PATCH

D. DELETE

Correct Answer: A. GET

Question 5

What does HTTPS add to HTTP?

A. Guaranteed correct business logic

B. TLS-based encryption, integrity, and certificate-based authentication

C. Automatic protection from all client-side attacks

D. A requirement that every response be JSON

Correct Answer: B. TLS-based encryption, integrity, and certificate-based authentication

Question 6

Which status-code class indicates an apparent client-side error?

A. 2xx

B. 3xx

C. 4xx

D. 5xx

Correct Answer: C. 4xx

Question 7

What is the main purpose of the browser DOM?

A. To represent a document as a structure that scripts and browser systems can work with

B. To assign IP addresses to servers

C. To replace the database transaction system

D. To encrypt cookies automatically

Correct Answer: A. To represent a document as a structure that scripts and browser systems can work with

Question 8

Which REST constraint requires each request to contain sufficient context for processing?

A. Code-on-demand

B. Stateless communication

C. Mandatory XML representation

D. Single-server deployment

Correct Answer: B. Stateless communication

Question 9

Which developer-tools panel is most suitable for checking request status, headers, payloads, and timing?

A. Network

B. Elements

C. Sources only

D. Application manifest only

Correct Answer: A. Network

Question 10

Why should a registration system enforce course capacity on the server?

A. Browsers cannot display course names

B. Client code is trusted more than server code

C. Server-side enforcement protects business rules against concurrent and untrusted requests

D. React cannot render a registration button

Correct Answer: C. Server-side enforcement protects business rules against concurrent and untrusted requests