Web Architecture

The big wonderful journey of a tiny request.

1. Click links or type URLs in your browser
That's you ;)
18. Your browser prints out HTML nicely, or informs you about what happened.
That's also where JavaScript is run, so you can have rich interactions.
2. The browser sends out a request.
That's the application you use to browse the Internet.
Examples: Firefox, Chrome, Safari, Opera... there's Internet Explorer too, but we developers love to hate it ;)
Web browser
3. The request is sent on the network (eg. Internet).
That's information about who you are and what you want. Who you are: it depends, but mostly your IP (who to answer to), some imformation about your computer (browser you use, screen size, previous URL). What you want: the URL, some parameters, form content, and all cookies.
See Request in HTTP
17. All the way back!
4. A network of links and equipments will find where your request should go.
The Internet is a series of tubes? More like a mesh of servers, linked by connections like cable, fiber, wifi or satellite links.
Computer Network
16. The response is sent back, the same way the request was sent.
You asked a question, the web server answers you. This is the response you waited, with your carefully crafted content.
See Response in HTTP
Web Server
15. The web server sends back what the app server gave it.
5. The web server gets the request, and finds out if it can send a file or call other pieces of software.
This means both a machine (or several machines), or a piece of software which purpose is to handle your request, then calling any other piece of software the programmers decide, then sending back a response.
Web Server
  Files are sent back directly.
The web server could find a file to send directly.
If there is no clever stuff involved, and you asked for a file like a picture (which is not supposed to change often), the server can send it back very quickly, and avoid calling 'clever' code.
6. Some routing rules (either on the web server, app server or both) are used to send the request where it's appropriate.
There are plenty of things you can do, so there are plenty of code bits too.
The routing is responsible for calling the right piece of code.

Each framework has its kind of routing, so here is how Ruby on Rails' routing work.
14. Sends the HTML back. If you didn't render a view, you should return raw data, status codes, or redirections.
7. This is where the code is involved!
App Server
The app server runs the code. It needs to do smarter things than the web server, so we often like to separate them, just in case the full-fledged App Server is not required and the Web Server is enough to do the job.
Application Server
13. the view is rendered with the data that came back.
Views are mostly HTML snippets, with placeholders the Controller will fill.
View in MVC
12. The controller can also apply application rules once it gets the data from the model.
8. The app server calls an action to handle the request.
If you use an MVC framework, the Controller handles the request. The controller does some application logic.
Controller code can do some security checks, then ask for the right pieces of data from the Model, run the View, and send you back some kind of response: content, files, or maybe a redirection, which is his way of saying "someone else should handle this".
Controller in MVC
11. The model can still adapt and apply business rules once it gets the data.
9. The model answers to each question the controller asks him.
If you use and MVC framework, the Controller asks the Model for data. The model knows some business logic, and connects to the database.
How to know if code should go into the model or controller? If
  1. you make something that is not a web app, and the rules would be the same
  2. you make several applications, and this logic is the same across all these
  3. the controller is too long, you should probably put some code in the model to "help" it

Model in MVC
10. the database queries data or writes the updates.
The database is where your data is stored safely. These run very specialized software, optimised for fast search and/or high availability.
Each one ensures some properties, like keeping the data even if there is a power outage.