Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions .gitattributes
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
/courses/Foundation/web-architecture-101/presentation/web-architecture-101.pdf linguist-generated=true
/courses/Foundation/web-architecture-101/presentation/web-architecture-101.zip linguist-generated=true
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
# Ignore hidden Mac OS directory files
**/.DS_Store
courses/Foundation/web-architecture-101/presentation/web-architecture-101/
node_modules/
support/dist/
1 change: 1 addition & 0 deletions .prettierignore
Original file line number Diff line number Diff line change
@@ -1 +1,2 @@
/support/dist/
/courses/Foundation/web-architecture-101/HYF Web Architecture 101/
21 changes: 20 additions & 1 deletion courses/Foundation/web-architecture-101/README.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,22 @@
# Web Architecture 101

TODO
This module takes a rather different form from all of the other modules.
It's in the form of a presentation, which is provided here in Keynote, PDF, and HTML forms.

The purpose of this module is to provide a mental model of how the remaining technical modules fit together.

You don't have to _remember_ and _learn_ everything in the presentation.
Instead, it's all about getting an overview of how web sites work, some of the terminology,
and how that relates to the coming modules.

After the presentation, you may find the [recap](./recap.md) useful.

## The presentation

- in its original [Keynote format](./presentation/web-architecture-101.key)
- exported as a [PDF](./presentation/web-architecture-101.pdf)
- exported as [HTML](./presentation/web-architecture-101.zip) (zipped)

---

_Notes for mentors: see [goals](./goals.md) and [structure](./structure.md) to see how this module is put together._
26 changes: 26 additions & 0 deletions courses/Foundation/web-architecture-101/goals.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
# Goals

The goals of WebArch101 are:

- To provide a mental model into which the other technical modules fit.

## Detail

The technical modules (across Foundation, Back End specialism, and Front End specialism)
are:

- HTML & CSS
- JavaScript / Advanced JavaScript
- Databases
- Intro to backend
- Intro to frontend
- React
- Final project (to the extent that stuff needs to be deployed)

It is these modules which we aim to present together in a coherent model.

_Not_ in scope for WebArch101:

- Git / Collaboration via Git
- Team processes / Advanced team processes
- Career training / Specialist career training
Binary file not shown.
Binary file not shown.
Binary file not shown.
37 changes: 37 additions & 0 deletions courses/Foundation/web-architecture-101/recap.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Recap

## Front end vs back end

Web development spans:

- the front end (stuff that happens in the users' web browsers);
- the back end (stuff that happens on servers that we control).

The front end and the back end communicate via HTTP. The front end makes a request, and the back end answers with a response.

We get to write the software on both sides.

## What happens in the front end

- in the front end:
- we can only use JavaScript;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can use so many more things though - html, css + loads of advanced magic.

I understand what this means, but I'm worried that at this stage trainees take things very literally. Perhaps being more verbose could be useful, like:

Suggested change
- we can only use JavaScript;
- we use HTML & CSS to format and style documents
- we use JavaScript to introduce any interactive logic
- there is a variety of languages and frameworks available, but ultimately in the web all needs to transpile to JavaScript

- we can do things like manipulate the web page, or make a request to the server.

## What happens in the back end

- in the back end:
- the primary goal is to send back a response for each HTTP request;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- the primary goal is to send back a response for each HTTP request;
- we define the endpoints for the HTTP requests
- we define what data can be send back to frontend per each endpoint
- we define the structure of the data to be send to the frontend

again, for verbosity. It is the backend that defines the endpoints.

- we can use any language we like (but we'll be using JavaScript);
- we can also do things like read and write files (on the server), or talk to a database, or to another server.

## Data & APIs

TODO

## Deployment

The server is ours to control. It runs the back end code.

It also has a copy of the front end code, so that it can provide it to the front end, for the web browser to run it.

"Deployment" is about making sure that the server has all the code, other files, and settings that it needs.
66 changes: 66 additions & 0 deletions courses/Foundation/web-architecture-101/structure.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
# The structure of this presentation

## 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
Comment on lines +11 to +19

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all of that is going waaaaay to deep for foundation to web dev. Just quantity of new names and acronyms in this recap is overwhelming. I can already see they synapses fry when mentor explains protocols or the binary cat picture :D

I'm no saying it's not relevant, because it is. I am concerned though about the retention of the focus. Knowing http protocol intricacies is not applicable at this level, therefore will not be retained.

what could be done instead is:

  • explain what an endpoint is (address to call for data over network - metaphore prefered here)
  • stucture of endpoint could be explained on domain + stuff basis, maybe with relevance to the systems paths so trainees have something to associate it with
  • different types of requests (GET, POST, PUT, DELETE) - briefly, on metaphores. Payloads and such will come with backend implementation or frontend - i'm not even sure about this. I think this should come later too.
  • I would put the communication tool AFTER explaining the layers it could communicate between
  • you could consider consolidating all the great work you did with this module to a pre-read or a bonus read for the curious :)


## 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 front end

Key points:

- Usually the starting URL is going to be `text/html`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's if you actually discuss content type, which at this level i would advise against

- How HTML refers to other resources
- JavaScript is the only available language

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why? How does browser work? What happens when I type url and I can see the page?

They don't know that at this level. On this level it is good to show a browser diagram or a metaphore to explain:

  • that browser is just an advanced engine for displaying documents
  • that it all started from displaying academic papers, like MS Word
  • therefore the core of everything is HTML and what that is (some may not know even that!)
  • that styling is done with CSS and it's also a scripting syntax
  • you can, in fact, have the website with no js. Why do we need js then?
  • bonus could be to show possibilities - yes, facebook or github are web pages, but so are web games (your example) or 3D three.js experiences (some example from FWA could be nice for wow effect).

I'm not saying my material is excellent but at JS2 I used these metaphores and trust me, there were questions :D
https://github.com/magdazelena/hyf-js2-week1

- What JavaScript in the browser can and can't do
- Typical things we'll do with front-end JavaScript

## The back end

Key points:

- http 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
Comment on lines +45 to +49

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also would like to argue that not at this point. I would put that into the advanced read, and talk more about:

  • data
  • security
  • optimisation & communication between services
  • modern backend in the workplace it's not going to be static server to display a website, it will be cloud architectures, systems, services -> still pointing to a frontend

If this is a foundation to explain what path each specialisation will open, I would advise against going into specifics, but rather showing the big picture on clear examples. Use of metaphores and in general reference to what trainees KNOW already is a great way to slide into their minds.

I would be thrilled at this level if someone explained to me how, idk, facebook backend works (of course in no details). Where is the data, how is it gathered, how does it even know it's me (auth). So much power and excitement there.


## Data and APIs

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and this is where I would suggest communication layer (like I wrote in other comment)


Key points:

- TODO
- data store services (in the abstract). Peristing 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