Web Application Architecture and Design Patterns
A presentation deck for Week 2 that explains how modern web systems are structured, how requests move, and how common design patterns shape maintainable applications.
- Covers all six Week 2 topics in an expanded slide deck.
- Designed for class delivery, revision, and recap.
- Use arrow keys, buttons, or slide dots to navigate.
Focus
Week 2 Presentation
Use
Teach this page live or review it before class.
What this week is about
Week 2 moves from web foundations into system structure and software organization.
- 2.1 Web Application Architecture Overview
- 2.2 Client-Server Model
- 2.3 Request-Response Cycle
- 2.4 MVC Design Pattern
- 2.5 Component-Based Architecture
- 2.6 RESTful Architecture
Focus
Overview
Use
Teach this page live or review it before class.
Web application architecture organizes complexity
Architecture explains how the parts of a web application fit together and how responsibilities are separated.
- Architecture is about structure, not just code style.
- It defines where presentation, logic, and data handling live.
- Good architecture improves maintainability, scalability, and testing.
Focus
2.1 Architecture
Use
Teach this page live or review it before class.
Most web systems are layered
A layered system splits the application into parts so each layer focuses on a single kind of work.
- Presentation layer handles what the user sees.
- Application or business layer manages rules and workflows.
- Data layer stores and retrieves persistent information.
- Support services provide authentication, caching, logging, and APIs.
Focus
2.1 Layers
Use
Teach this page live or review it before class.
Separation of concerns keeps systems manageable
When each part has a clear responsibility, the application is easier to understand and evolve.
- Developers can change one layer without rewriting everything.
- Testing becomes easier because modules have smaller responsibilities.
- Teams can collaborate because work is organized by concern.
Focus
2.1 Why it matters
Use
Teach this page live or review it before class.
Choose the right architecture for the job
A design should match the size of the project, the team, and the expected change rate.
- A simple monolith can be the best starting point for small projects.
- A modular structure helps teams keep responsibilities separate without extra complexity.
- More distributed styles only make sense when the project really needs them.
Focus
2.1 Trade-offs
Use
Teach this page live or review it before class.
The client-server model is the basic web relationship
The browser acts as the client and the application host acts as the server.
- Clients request resources, data, or actions.
- Servers respond with HTML, JSON, files, or status messages.
- The model allows work to be shared between user devices and servers.
Focus
2.2 Client-Server
Use
Teach this page live or review it before class.
The browser and server do different jobs
The client focuses on interaction while the server focuses on rules, persistence, and security.
- The browser displays the interface and handles user events.
- The server authenticates users and protects the data.
- Both sides collaborate to create the final experience.
Focus
2.2 Roles
Use
Teach this page live or review it before class.
Client-server makes the web scalable and flexible
Separating the interface from the backend supports reuse, scaling, and different device types.
- Multiple clients can use the same backend services.
- Servers can be upgraded without redesigning every browser screen.
- The same backend can serve web, mobile, or API consumers.
Focus
2.2 Benefits
Use
Teach this page live or review it before class.
A request-response cycle powers every interaction
The browser sends a request, the server processes it, and the response returns to the client.
- Requests may be GET, POST, PUT, DELETE, or other HTTP methods.
- Responses include status codes, headers, and content.
- Each interaction is a cycle, even when it happens very quickly.
Focus
2.3 Request-Response
Use
Teach this page live or review it before class.
Request handling follows a sequence
The flow shows how a single user action moves across the system before the response reaches the screen.
- User action starts in the browser.
- The request is sent over HTTP to the server.
- The server validates, processes, and queries data if needed.
- The server returns a response that the browser renders.
Focus
2.3 Flow
Use
Teach this page live or review it before class.
Understanding the cycle helps debugging
If you know where the cycle failed, you can find the bug faster.
- Broken input can fail before the request reaches the server.
- Server errors create 4xx or 5xx responses.
- Performance issues may appear in network, server, or database stages.
Focus
2.3 Why it matters
Use
Teach this page live or review it before class.
Use response codes, logs, and network tools together
A good debugging workflow checks the browser, the network response, and the server logs.
- Use the browser network tab to inspect the request and response.
- Match the status code with the error the user sees.
- Check logs and payloads before guessing at the cause.
Focus
2.3 Debugging
Use
Teach this page live or review it before class.
MVC separates concerns inside an application
Model-View-Controller is a design pattern that divides data, presentation, and interaction logic.
- Model represents data and business rules.
- View renders what the user sees.
- Controller receives input and coordinates actions.
Focus
2.4 MVC
Use
Teach this page live or review it before class.
MVC improves organization and reuse
By keeping roles separate, MVC helps teams build cleaner and easier-to-test code.
- Views can be changed without rewriting business logic.
- Controllers stay focused on request handling.
- Models can be reused across multiple interfaces.
Focus
2.4 MVC benefits
Use
Teach this page live or review it before class.
Component-based architecture builds software from reusable parts
A component is a self-contained piece of the application that can be reused and combined with others.
- Components improve consistency and reduce duplication.
- UI components can represent buttons, cards, forms, and menus.
- Backend components can handle authentication, storage, or messaging.
Focus
2.5 Components
Use
Teach this page live or review it before class.
Component-based thinking supports maintainability
Reusing pieces instead of copying code makes it easier to change and scale the application.
- A component can be updated once and reused everywhere.
- Small components are easier to test than large monolithic blocks.
- Clear interfaces make integration safer.
Focus
2.5 Reuse
Use
Teach this page live or review it before class.
Good components have clear inputs and outputs
A component is easier to use when its job, data, and output are explicit.
- Explicit props or parameters make reuse predictable.
- A narrow responsibility keeps the component easier to test.
- Stable interfaces let other parts of the system depend on the component safely.
Focus
2.5 Boundaries
Use
Teach this page live or review it before class.
RESTful architecture treats the web as resources
REST organizes services around resources addressed by URLs and manipulated with HTTP methods.
- Resources represent things such as users, posts, or orders.
- GET reads data, POST creates, PUT or PATCH updates, and DELETE removes.
- REST helps build APIs that are simple and predictable.
Focus
2.6 REST
Use
Teach this page live or review it before class.
RESTful APIs should be clear and stateless
A well-designed API returns understandable responses and keeps each request independent.
- Each request contains enough information to be processed independently.
- Status codes communicate success and failure clearly.
- Consistent URLs and response formats make APIs easier to consume.
Focus
2.6 API design
Use
Teach this page live or review it before class.
REST design should stay consistent over time
Good API design is about conventions, readability, and predictable behavior.
- Use resource names that are simple and consistent.
- Keep HTTP methods aligned with the action you want to perform.
- Plan versioning early so the API can evolve without breaking clients.
Focus
2.6 Checklist
Use
Teach this page live or review it before class.
What students should remember
Week 2 is about structure, separation, and communication across the web application stack.
- Architecture defines how a web app is organized.
- Client-server and request-response explain how the web works.
- MVC, components, and REST give developers reusable design patterns.
- Good architecture leads to software that is easier to build, test, and evolve.
Focus
Recap
Use
Teach this page live or review it before class.