Bootstrap 5 PHP Rendering Architecture Patterns

Week 2 System Brief

Web Application Architecture and Design Patterns

Study how web applications are structured, how requests flow, and how architectural patterns such as MVC, components, and REST keep systems maintainable as they grow.

Explore Topics Open Presentation Back to Week 1 Book
Topics 6 Core concepts for Week 2
Objectives 18 Learning goals across the week
Review Prompts 12 Questions for revision and reflection
Architectures 6 Patterns covered in the book

Week 2 Content

Structure, interaction, and design patterns

Each topic combines objectives, discussion notes, a diagram, an applied example, and review questions so the book can support reading and teaching.

Architecture, MVC, components, REST
Topic 2.1 3 deep dives 2 review questions

Web Application Architecture Overview

Architecture explains how a web application is structured, how responsibilities are separated, and how the parts collaborate to deliver a system that is maintainable and scalable.

Topic Build
Objectives 3
Deep dives 3
Review prompts 2
Learning Objectives
  • Define web application architecture and explain why it matters.
  • Identify the major layers in a typical web system.
  • Relate architecture decisions to maintainability, scalability, and testing.
Discussion Notes

Read these notes in order to understand the topic clearly.

01

Architecture is the high-level structure of a software system. It decides where presentation, business logic, data handling, and supporting services live.

02

A well-structured architecture reduces duplication, makes debugging easier, and helps teams work on different parts of the system in parallel.

03

Architectural decisions affect the whole lifespan of the application. Poor structure becomes expensive to change as the project grows.

04

The goal is not to add layers for their own sake, but to give each part of the system a clear responsibility.

System Insights

When architecture is clear, the application is easier to reason about. A developer can tell where a problem should be fixed because each module or layer has a defined role. This separation also helps teams document systems and onboard new developers faster.

A design decision that looks small at first may become important when traffic grows or the application needs new features. Architecture therefore acts like a roadmap for future change, not just a drawing of the current codebase.

Architecture must support quality goals such as performance, security, and scalability. These non-functional requirements often decide whether a layered system will remain practical as the workload grows.
Architecture Diagram Click to zoom
Architecture Layers Presentation Layer Application / Business Layer Data Layer and Supporting Services
Applied Example

A student portal might place the login interface in the presentation layer, registration rules in the business layer, and student records in a data layer. If the university later changes the UI, the record storage and business rules can remain stable.

Review Questions
  1. Why does architecture matter beyond the first version of the application?
  2. How does separating responsibilities help a team maintain software?
Key Takeaways
  • Architecture defines structure and responsibility.
  • Good structure makes change safer and easier to manage.
  • Architectural decisions influence the full life of the application.
Topic 2.2 3 deep dives 2 review questions

Client-Server Model

The client-server model is the basic relationship behind the web: the browser asks for something, and the server responds with data, markup, or another action result.

Topic Build
Objectives 3
Deep dives 3
Review prompts 2
Learning Objectives
  • Explain the roles of the client and the server in web applications.
  • Describe how the client-server model supports shared services and scalability.
  • Recognize why the browser and server have different responsibilities.
Discussion Notes

Read these notes in order to understand the topic clearly.

01

The client is usually the browser. It presents the interface, collects input, and sends requests when the user interacts with the page.

02

The server hosts the application logic and often owns access to data, authentication, and security checks.

03

The same server can support many clients at once, which makes the model practical for web systems.

04

The model also allows the interface to evolve without forcing changes to the backend data rules.

System Insights

Client code can improve responsiveness and usability, but it should not be trusted for final validation or security. The browser is part of the experience, but the server remains the source of truth for protected data and critical rules.

The server processes requests, decides what action should happen, and returns an appropriate response. It often interacts with databases, file storage, authentication systems, and other services before generating the result.

The split between client and server also adds network cost. Good design reduces unnecessary round trips, keeps payloads small, and caches stable data so the application stays responsive.
Architecture Diagram Click to zoom
Client and Server Roles Client Browser, interface Server Logic, data, rules
Applied Example

In an online bookstore, the browser displays the catalog and shopping cart while the server calculates totals, checks stock, and records the order. The same backend can also support a mobile app or API consumer.

Review Questions
  1. What tasks belong to the client and what tasks belong to the server?
  2. Why is the client-server model useful for web applications?
Key Takeaways
  • The browser is the client and the application host is the server.
  • The client handles interaction; the server handles logic and data.
  • One backend can serve many different clients.
Topic 2.3 3 deep dives 2 review questions

Request-Response Cycle

The request-response cycle is the basic communication pattern on the web. A browser sends a request, the server processes it, and the response returns to the client.

Topic Build
Objectives 3
Deep dives 3
Review prompts 2
Learning Objectives
  • Describe the sequence of events in a request-response cycle.
  • Recognize the role of HTTP methods and status codes.
  • Use the cycle as a way to understand debugging and performance issues.
Discussion Notes

Read these notes in order to understand the topic clearly.

01

Each web interaction begins with a request that includes a method, a target URL, headers, and sometimes a body of data.

02

The server interprets the request, validates it, performs the required work, and sends back a response.

03

Responses include status codes, headers, and content such as HTML, JSON, or file downloads.

04

If you understand where a failure happened in the cycle, you can debug more quickly.

System Insights

GET usually reads data, POST creates or submits data, PUT or PATCH updates, and DELETE removes resources. The method matters because it tells the server what action the client wants to perform.

HTTP status codes are part of the conversation between client and server. A 200 response means success, 404 means the resource was not found, and 500 indicates a server-side problem. These codes help both users and developers understand what happened.

Headers, cookies, and payloads provide the context the server needs to process the request correctly. Knowing where each piece of information lives helps explain why one request works and another one fails.
Architecture Diagram Click to zoom
Request-Response Cycle 1 2 3 Browser request Server processing Browser response
Applied Example

When a student submits a registration form, the browser sends the form data to the server, the server checks the information and updates the database, and the browser displays success or error feedback based on the response.

Review Questions
  1. What are the main parts of a request and a response?
  2. How do status codes help during debugging?
Key Takeaways
  • Web interactions follow the request-response cycle.
  • HTTP methods describe the type of action being requested.
  • Status codes communicate the result clearly.
Topic 2.4 3 deep dives 2 review questions

MVC Design Pattern

Model-View-Controller is a design pattern that separates data, presentation, and control logic so web applications are easier to build and maintain.

Topic Build
Objectives 3
Deep dives 3
Review prompts 2
Learning Objectives
  • Define the Model, View, and Controller roles.
  • Explain how MVC improves organization in web applications.
  • Relate MVC to maintainability and reuse.
Discussion Notes

Read these notes in order to understand the topic clearly.

01

The Model represents data and business rules. It often connects to databases or domain objects.

02

The View renders what the user sees. It focuses on presentation and display logic.

03

The Controller receives input and coordinates the application flow between the model and the view.

04

MVC is popular because it keeps the different concerns from becoming tangled together.

System Insights

The model is the system knowledge layer. It knows what the data means, how it is stored, and what rules apply to it. By isolating this logic, applications can reuse the same model in different interfaces.

The view should be concerned with display, while the controller should be concerned with request flow. This division keeps interface code clean and prevents business logic from leaking into templates.

A common problem is letting controllers become too large or placing presentation logic inside the model. Clean MVC keeps each role narrow so the application does not drift into a tangled structure.
Architecture Diagram Click to zoom
MVC Pattern Model Data and rules View Presentation layer Controller Input and flow
Applied Example

In a course management system, the model stores course and enrollment data, the controller handles student actions, and the view renders the list of registered courses. A change in layout does not have to alter the data model.

Review Questions
  1. What does each part of MVC do?
  2. Why does MVC make a project easier to maintain?
Key Takeaways
  • MVC separates data, display, and control.
  • The pattern improves readability and reuse.
  • Controllers coordinate, models store meaning, and views render output.
Topic 2.5 3 deep dives 2 review questions

Component-Based Architecture

Component-based architecture builds the system from reusable pieces that can be composed into larger features and interfaces.

Topic Build
Objectives 3
Deep dives 3
Review prompts 2
Learning Objectives
  • Explain what a component is in a web application.
  • Describe how components support reuse and consistency.
  • Recognize the maintainability benefits of component-based design.
Discussion Notes

Read these notes in order to understand the topic clearly.

01

A component is a self-contained unit with a clear purpose and interface.

02

In the UI, components may represent cards, buttons, forms, menus, or data panels.

03

In the backend, components can represent authentication, email delivery, storage, or caching services.

04

A component-based system is easier to scale because parts can be reused across pages and features.

System Insights

Reusing a component reduces duplication and keeps the user experience consistent. When the same card or control appears across the application, users learn the interface faster and developers maintain fewer copies of the same code.

A component should do one job well and expose a simple interface. That independence makes it easier to test, replace, and integrate with other parts of the system without spreading changes everywhere.

Components work best when their inputs and outputs are clear. Strong boundaries make composition predictable and allow one component to be replaced without forcing changes across the whole application.
Architecture Diagram Click to zoom
Component-Based Design Header Reusable UI Card Composed block Footer Reusable UI
Applied Example

A dashboard can reuse one notification component, one profile card component, and one statistics card component across multiple pages. The design stays consistent and the code is easier to evolve.

Review Questions
  1. What is a component in the context of web architecture?
  2. How does reuse help both developers and users?
Key Takeaways
  • Components are reusable building blocks.
  • Consistent components reduce duplication.
  • Small, independent parts are easier to test and maintain.
Topic 2.6 3 deep dives 2 review questions

RESTful Architecture

REST organizes web services around resources and uses HTTP methods and URLs in a consistent way so APIs remain predictable and stateless.

Topic Build
Objectives 3
Deep dives 3
Review prompts 2
Learning Objectives
  • Explain the idea of resources in REST.
  • Match HTTP methods to RESTful actions.
  • Describe why statelessness and clear URLs matter in API design.
Discussion Notes

Read these notes in order to understand the topic clearly.

01

REST treats things such as users, courses, or orders as resources.

02

Each resource is identified by a URL, and HTTP methods describe what action is being taken on that resource.

03

RESTful APIs should be predictable, stateless, and consistent in their use of status codes and response formats.

04

This style works well for services that are consumed by web apps, mobile apps, and other systems.

System Insights

When APIs are designed around resources, developers can guess the structure of the endpoint more easily. Good resource design makes the service easier to learn and reduces confusion for clients.

Statelessness means each request contains enough information to be processed independently. This makes services easier to scale and helps avoid hidden dependency problems between requests.

REST APIs are easier to use when resource names are consistent, status codes are meaningful, and versioning is planned carefully. Predictable conventions reduce mistakes for both humans and code.
Architecture Diagram Click to zoom
REST Resources /tasks Collection GET POST Methods /tasks/15 Single resource
Applied Example

A task tracker might expose /tasks for listing and creating tasks, /tasks/15 for reading one task, and use GET, POST, PATCH, and DELETE to manipulate those resources in a consistent way.

Review Questions
  1. What makes an API RESTful?
  2. Why is statelessness useful in service design?
Key Takeaways
  • REST organizes APIs around resources.
  • HTTP methods describe actions on those resources.
  • Statelessness and consistency improve scalability and usability.
6 questions True / False Auto-marked

Week 2 Quiz

Answer each statement, submit the quiz, and review the score with the correct answers shown underneath.

Quiz Rules
Total items6
Pass mark70%
GradingInstant

Enter your Name and Matric No, then press Start Quiz to begin the attempt.

The quiz stays hidden until you start it, just like Quiz 1.

Press Start Quiz to open the questions and begin the attempt.