# Session Plan

## Session materials

These are some examples of previously created materials by mentors that you can use yourself, or for inspiration.

* Intro to Web Architecture ([key](https://github.com/HackYourFuture-CPH/program/blob/main/courses/foundation/intro-to-web-architecture/session-materials/web-architecture-101.key), [pdf](https://github.com/HackYourFuture-CPH/program/blob/main/courses/foundation/intro-to-web-architecture/session-materials/web-architecture-101.pdf), [zip](https://github.com/HackYourFuture-CPH/program/blob/main/courses/foundation/intro-to-web-architecture/session-materials/web-architecture-101.zip) by [@rvedotrc](https://github.com/rvedotrc))

## Session outline

### Introduction

Key points:

* This module is rather different from the other technical modules
* You don't have to remember everything in this module
* The purpose of this module is to give an understanding of how the remaining modules fit together

### HTTP

Key points:

* The structure of a URL (scheme, host, path)
* Finding a host with DNS
* Establishing a connection (TCP)
* Content-Type instead of file extension
* An HTTP GET request/response, at the most simple level

### Front end vs back end

Key points:

* To make our web page available, we have to have a server
* That server needs to run some software: a web (http) server
* The server needs whatever software *it* runs, plus files for the browser
* Some of our code runs in the browser; some of our code runs on the host
* This is "front end" and "back end"
* The frontend and backend communicate via HTTP. Frontend makes a request, and backend answers with a response.
* We get to write software for both sides.

### The front end

Key points:

* Usually the starting URL is going to be `text/html`
* How HTML refers to other resources
* JavaScript is the only available language
* What JavaScript in the browser can and can't do
* Typical things we'll do with front-end JavaScript, like manipulating web pages and making requests to servers

### The back end

Key points:

* The primary goal is to send back responses for every HTTP request
* HTTPS listen, handle request
* What HTTP requests/responses "look like"
* Serving static content
* It is just software. We can extend it!
* Any language, but we'll be using JavaScript
* We can also do things like read and write files (on the server), talk to a database or to other servers

### Data and APIs

Key points:

* What an API is
* JSON as the common data format
* **CRUD** stands for **Create, Read, Update, Delete** - the four basic operations for managing data. Conceptual introduction - we'll explore CRUD in detail in the databases module
* These operations map to HTTP methods:
  * **Create** → add new data
  * **Read** → retrieve data
  * **Update** → modify existing data
  * **Delete** → remove data
* Most web applications are essentially CRUD applications with a user interface
* HTTP methods:
  * `GET` = retrieve data = R(ead) in CRUD
  * `POST` = send data = C(reate) in CRUD
  * `PUT` = update data = U(pdate) in CRUD
  * `DELETE` = delete data = D(elete) in CRUD
* How different methods carry data:
  * `GET` → uses query parameters
  * `POST`, `PUT` → use request body
  * `DELETE` → usually no data
* Role of content type: servers specify how to interpret data (e.g. `application/json`)
* Idea that "the page" and "the data" are separate things
* Data store services (in the abstract). Persisting data away from the web server.

### More complex setups

Key points:

* This section talks about things *beyond* what Hack Your Future covers
* It's a taster of what things start to look like in larger, real-world scenarios
* The client/server terminology
* Adding a database server
* Multiple environments
* Deployment is about making sure the server has all the code, files and settings that it needs

## Exercises

### HTTP Request Analysis

Analyze the following URL and break it down into its components:

`https://api.github.com/users/octocat/repos?sort=created&per_page=10`

1. Identify the scheme, host, path, and query parameters
2. What HTTP method would be used to access this URL?
3. What Content-Type would you expect in the response?
4. What happens when you type this URL in a browser?

### Frontend vs Backend vs Database Classification

Categorize the following statements into: **Frontend**, **Backend** or **Database**:

* "Runs in the user's browser"
* "Handles HTTP requests and responses"
* "Can manipulate the DOM"
* "Stores user information permanently"
* "Sends JSON data to the server"
* "Validates user input before saving"
* "Renders HTML pages"
* "Connects to a database"
* "Executes JavaScript on the server"
* "Serves static files like CSS and images"
* "Processes form submissions"
* "Shows a loading spinner while waiting for data"
* "Encrypts passwords before storing them"
* "Updates the page without refreshing"
* "Sends emails to users"

Work in small groups and present your categorization to the team.

### API Design

Design an API for an advanced to-do list application for teams.

*Note: You don't need to create proper REST endpoints - just focus on the basic structure and HTTP methods.*

Design endpoints for:

* Getting all tasks
* Getting a specific task
* Creating a new task
* Updating a task (e.g., changing status, assigning to user)
* Deleting a task

For each endpoint, specify:

* HTTP method
* URL path
* Request format (if applicable)
* Response format
* Status codes

Example:

```markdown
GET /api/tasks
Response: 200 OK
Content-Type: application/json
Body: [{"id": 1, "title": "Fix login bug", "description": "Debug authentication issue", "status_id": 2, "user_id": 2, "created": "2024-01-15 10:30:00", "updated": "2024-01-15 14:20:00", "due_date": "2024-01-20 17:00:00"}]
```

*Note: This design will be revisited in upcoming modules - you'll create the database in the databases module and implement these endpoints in the intro-to-backend module!*

### System Architecture Design

*This should be done as a collaborative demo with the mentor leading and asking questions to trainees.*

#### Part 1: Architecture Diagram (Mentor Demo)

Design a simple to-do list application with basic CRUD operations:

1. **Create**: Add a new todo item
2. **Read**: Display all todo items
3. **Update**: Mark a todo as completed
4. **Delete**: Remove a todo item

**Mentor should:**

* Help trainees to visualize application first
* Draw the architecture diagram on a whiteboard/digital tool while asking trainees questions
* Guide trainees to identify: frontend, backend, database components
* Ask: "Where should the todo data be stored?" "How does the frontend talk to the backend?"
* Keep it simple - just one page with a list of todos and basic functionality
* Show a simplified example (not professional-level complexity)

#### Part 2: Sequence Diagrams (Mentor Demo + Trainee Exercise)

**Mentor Demo (first 2 flows)**

* Explain what sequence diagrams are with simple examples
* Demonstrate CREATE and READ flows step-by-step
* Show the communication: User → Frontend → Backend → Database
* Use simple format like:

  ```
  User → Frontend → Backend → Database
  User clicks "Add Todo" button
  Frontend sends POST /todos with todo data
  Backend saves data to database
  Backend sends success response
  Frontend updates the page
  ```

**Trainee Exercise**

* Work in pairs to create sequence diagrams for UPDATE and DELETE flows
* Share results with the rest of the trainees
* Mentor shows "correct" examples at the end

*Note: This prepares trainees for the assignment, therefore can't be skipped.*