Going into the design semester at Starter School, I knew I would have to keep my Ruby and Rails skills sharp on my own. The best way to do this is definitely to just build more apps, but I also wanted to get a better understanding of what’s going on under the hood of Rails. Luckily, we have some great mentors at Starter School, one of which recommended me a book called Rebuilding Rails(Thanks Alex). In the book, Noah Gibbs takes you through constructing your own Ruby web framework, highlighting parallels to Rails along the way. Here are some cool things I took away from the first chapter:

Rack tells Rails how to talk to the server

Rack is web server interface written in Ruby. That’s just a fancy way of saying it tells servers how to communicate with Rails and vice versa. Getting a simple page with text running with Rack is really simple:

When a HTTP request is made, Rack asks the server to organize the information in a Ruby hash called env that looks like this:

```ruby env hash env = { ‘REQUEST_METHOD’ => ‘GET’, ‘PATH_INFO’ => ‘/users’, ‘HTTP_VERSION’ => ‘1.1’, ‘HTTP_HOST’ => ‘localhost’, … … }


Rails takes the info from the <code>env</code> hash and sends back a response. The response is an an array with three element: the status code, the header hash, and the body. A typical response would look like this:

```ruby response
[
  200,
  {"Content-Type" => "text/html"},
  ["<h1>","Hello!","</h1>"]
]

Depending on whether the request was successful or not, these values change. Here is a list of HTTP response headers and status codes.

For your Ruby(or Rails) app to work with the env hash provided by the server, it must use the call method:

class App
  def call(env)
    [200, {"Content-Type" => "text/html"}, ["Hello!"]]
  end
end

If you want to do more than display more than plaintext on one page, it obviously gets more complicated, but I think it’s pretty cool how low the barrier is for getting something on a web page.

Rails is made up of five main pieces

It turns out that Rails is not just a monolithic hunk of complicated code - it is broken up into five main components, all with a specific job:

  1. ActiveSupport: extends much of the basic functionality of Ruby. This isn’t exclusively a part of Rails - you can include it in any other Ruby project. Some helpful things it includes are blank? and present?.
  2. ActiveModel: provides an API for models to use to be compatible with ActionPack’s helpers.
  3. ActiveRecord: known as an ORM(Object-Relational Mapper), it allows Ruby objects to communicate with a SQL database. ActiveRecord is what gives you the ability to use methods like find_by in your app to retrieve records from the database. This makes it a ton better than writing raw SQL all the time.
  4. ActionPack: takes care of several core parts of your application, one being the routing of requests to the correct controller actions. ActionPack uses Rack for translating the requests/responses between the server and the app.
  5. ActionMailer: does exactly what it sounds like it does: sends email from your app.