00:00:16.560
Hey guys, good morning! I'm Christopher Greene, or Chris Green, or whatever you want to call me. This is Aimee Simone. We're with Indy Labs and also with Code School. We have come to give you a little presentation about how requests become responses. It's going to be a kind of journey from the browser through the generation of a request, through the web server and app server, all the way up through the Rails stack, and back down to the client.
00:00:36.399
We'll touch on a lot of things, but we won't get into how to do this in detail. In the workshop section, you'll have access to Rails for Zombies and Rails Zombies 2, which will dive much deeper into how this stuff works. This presentation is more focused on understanding what is happening, how to trace it, and providing you with a vernacular—a nomenclature—so you can give this stuff context.
00:01:22.680
As Jeff mentioned, this is our workshop page. You can check out this page later; we will be posting our slides there. There's also a link to our chat room if you want to ask each other questions or answer questions during the session. Additionally, there are links to the materials we'll be using during the workshop. You won't need this right now, but feel free to pull it up if you'd like. We're going to go ahead and get started.
00:02:03.280
As Chris mentioned, we'll be following a request through the application stack. We'll start at the client, where the request is initiated in the browser, and follow it up through the Rails application until a response is formed. Then, we'll follow that response back through the stack to the browser.
00:02:34.040
So, what is a request? A request is a set of instructions that tells the server what kind of response we want. For example, this is the URL that you might type into a browser: 'codeschool.com/courses.' In our case, the request is made up of several different pieces that we need to understand. The first one I want to mention is the request path, which, in our example, is the 'courses' portion of the URL. This informs the server which resource we are looking for.
00:03:06.519
Next, we have the request verb or method. In our case, we're using a GET request, which retrieves information from our server. Other common request types include POST, which sends information to the server; PUT, which is similar to POST but updates information; and DELETE, which is self-explanatory as it removes information. We also have query data, which we could append to the URL. For instance, if we append '?page=2' to the request, it would let our application know we are looking for the second set of results, perhaps when using pagination. Lastly, we have header data, which contains a lot of valuable information.
00:03:56.000
In the request header, some important elements specify the desired response type; for instance, here, we might ask for 'text/html.' We also include information about the requester, such as language preferences, which in this case is English, and the user agent, in our example Mozilla running on a Mac—this is useful information.
00:04:47.600
Now that we've talked about the different pieces of a request, we will follow 'codeschool.com/courses' from the browser to the web server. Just a look ahead: we expect a particular response when we initiate our request. We are looking for a page on 'codschool.com' that returns a list of courses. So in our browser, we type 'codeschool.com/courses,' which initiates the GET request from the browser to the web server. So, what is a web server?
00:05:20.560
A web server delivers web pages when requested by clients using HTTP. It also handles the delivery of application content. In the Rails environment, some examples of web servers you might see or use are Nginx, Apache, and Puma.
00:06:06.400
Next, we're going to be following the request from the web server to the app server. Once we've made the request and the web server accepts it, it's passed on to the application server. An app server handles the execution of procedures for an application. We won't delve too much into all the intricacies of how this works right now, but it’s crucial to note that the app server initiates Rails.
00:06:49.080
Some common app servers you might encounter in a Rails application are Passenger and Puma. So, to recap, our request has moved from the browser to the web server, which accepted it, and now it is passed to the app server.
00:07:36.640
The request is now handed over to Rails. I've handed it over to Christopher, who will discuss how we further process this request.
00:08:11.960
So, as we've discussed, we've moved from the client to the web server, and it passes our request to the application server. Once the application server is initialized with the request, it leads to starting up Rails. When the request hits Rails, the first point it encounters is the router. The router tells the Rails application where to route this request.
00:09:02.399
For instance, the router uses the request path to find the relevant resources. Remember that our request was a GET to 'codeschool.com/courses.' This is what a 'routes.rb' file looks like.
00:09:19.679
In the routes file, we define routes. Don't worry too much about the specifics right now; just focus on the fact that we have a resource called 'courses', which will lead to a match for various actions such as 'index' and 'show.' You can run the command 'rake routes', which tells you what is defined in this routes file.
00:09:56.760
When the router sees a request with the GET method directed at the path of 'codeschool.com/courses,' it looks for the corresponding controller and action, which is the 'index' action in this case. This means we know that the index action on the courses controller is next in line. This part of the process allows the request to be routed to the correct action.
00:10:32.960
Next, let's briefly discuss controllers and what they do. Essentially, a controller combines actions related to a particular resource. For our example of 'courses,' the goal is to retrieve a list of courses. The actions that would concern us would be 'index,' 'show,' 'create,' and 'update.' The naming conventions in Rails mean we can identify the controller associated with 'courses' as the 'CoursesController.' The action we are focusing on, right now, is the 'index' action.
00:11:42.200
Actions in a controller are where we gather the necessary information regarding a specific request. In our case, we want to gather the list of courses and present that information back to the view to be rendered. This process lays the foundation for creating specific responses that will eventually be passed to the user.
00:12:15.360
Next, we'll briefly discuss models. A model is an abstraction of some business object or requirement, such as a user or a course. In our learning scenario, the model represents the 'Course' and contains the necessary data we need to present.
00:13:02.440
Thus, our 'Course' and 'Path' models are linked to the database and help pull in the relevant information needed for rendering. This is how a controller action relates to a model—essentially, a model serves as a bridge, fetching data that the controller can then manipulate before rendering it to a view.
00:13:51.080
Moving up the stack, once a request is made, the web server processes it, passes it onto the app server, and initiates the Rails application. The app server then allows Rails to start its processes, which include analyzing the request, formatting the data, and preparing it for render.
00:14:36.640
Once Rails collects its data, we prepare to render a view. In our example, the view might be expected in certain formats such as HTML or HAML, based on our rails application configuration. The action that handles this data preparation also passes it along for rendering.
00:15:32.120
Once the data is prepared, the view processes the information. This can be likened to a template or a mail merge, producing the necessary HTML output. Eventually, this HTML becomes part of the response body sent back to the client.
00:16:23.600
Next, we need to understand what makes up the response. Earlier, we discussed what a request entails, in terms of passing information about what we are asking. The response headers include important information indicating the type of data being sent back. For example, if we requested 'text/html', the response would include headers confirming the content type is 'html.'
00:17:30.960
The status code of the response also conveys crucial information about the success or failure of the request. Common status codes include 200 (OK), indicating successful processing; 404 (Not Found), signaling that the requested resource does not exist; and 500 (Internal Server Error), reflecting issues on the server side.
00:18:36.280
In addition to these, the response may include additional data such as cookies, which can be utilized for authentication, and more detailed error messages if something goes wrong during the processing.
00:19:01.560
Finally, the response body contains the actual payload, whether it's HTML content, JSON data, or another file type. This component of the response is crucial as it provides the data required for the browser to construct what the user sees.
00:19:53.640
At this point, we have traversed the entire stack—from the originating request in the browser, through servers and Rails processing, and onto constructing and returning the response back to the browser. We’ve detailed how each component plays a role in delivering a seamless experience.
