Rails: An Unexpected Journey

Melissa Gonzalez
Jul 10, 2017 · 7 min read
Handrails provide structure to a bridge to allow us to cross the bridge more easily. Similarly, Rails provides structure in the Ruby language that allow us to create web applications more easily.

The word of the week is RAILS!

Rails is such a powerful tool, we spent most of last week learning various aspects of it. The journey from being a Rails newbie to proficient programmer will be long and arduous, but at least my path will be much less treacherous than that of the original Hobbit! At least I don’t have to deal with Dragons!

Ok, But What is Rails?

Rails is a framework of the Ruby language that allows developers to create web applications more easily. It consists of thousands of lines of code organized in various folders, and developers add to and modify this code in order to create their customize web application.

Similar to a handrail on a bridge, Rails provides added structure to allow us to accomplish our tasks faster and more efficiently. Handrails add structure to bridges to allow us to cross the bridge more safely and easily. In the same sense, Rails provides structure in Ruby that allow us to create web applications more easily. While you may be able to cross a bridge without a handrail or create a web app in Ruby without Rails, the task would take much longer and the likelihood for errors is much higher.

With Rails, the possibilities for creating different types of web apps are numerous. In order to use it, you must first install it into your computer. In class, we followed the instructions on gorails.com to install Ruby, Rails, Homebrew, Git, and PostgreSQL.

Once installed, the fun with Rails begins!


But first! Some Background

In order to understand the basic structure of using Rails, let’s back up and talk about how the Internet works. A fundamental understanding of the process will make it easier to learn how Rails is organizing and processing information.

The basic structure of the internet is that one computer (the client) requests information from another computer (the server). The server then receives & processes the request and sends a response back to the client.

The client refers to the computer the requests information. The server refers to the computer that stores & retrieves information.

Client requests take the form of an HTTP request. This means a user will either type a web address into their browser and hit send, or they click a link to a page they want to go to. In general, the server response is to return a particular html file or an error message.

However, between the client request and server response is where all the magic happens! And in this case, magic consists of code!


What is a Web Request?

We’ve all sent web requests, but what are they, exactly?

A web request consists of a verb, a web address, and a HTTP version. As users, we are generally only familiar with web addresses; the verb and HTTP version are information send by the browser to the server, and users never actually see these.

Verb

The most commonly used verbs that we as consumers generally use are: get, post, and delete.

  • GET is the verb used when we type a web address into a browser and expect a particular web page to come back. An example would be typing cnn.com into your browser and expecting to be able to read news.
  • POST is generally the verb used when we send information we expect to show up on a website or app. An example would be writing a blog post, hitting “Publish”, and expecting to see your article online on your blog.
  • DELETE is generally the verb used when we want to remove information from the internet. An example would be hitting the delete button on a Facebook post that you later regret posing.

IMPORTANT: The actions of the request verbs are not actually defined unless the developer defines them with code. For example, a regular user would not be able to go to CNN.com and delete a new story they didn’t like. A developer could also choose to have a “delete” request hide or archive a page rather than delete/remove it from the database, knowing users may change their mind later and want to retrieve the supposedly deleted information.

The Structure of a Web Address

A web address generally consists of 3 parts: the file type, the host or domain, and the url. Sometimes the entire web address is referred to as the url, but technically speaking, the url is only the part after the host.

Here’s an example:
http://domain_name.com/url

  • http is the file type. It stands for HyperText Transfer Protocol, which is the language that tells browsers how to process the information sent to them.
  • domain_name.com is the host or domain. It tells the browser where to look for the information that’s being requested.
  • /url is the url. Once the browser has located the host, the host’s server will look for the resources associated with the given url.

HTTP Version

The HTTP version is hidden information that the browser sends to the server so that it sends its web response in an appropriate format. It’s simply a way of making sure that the file being sent to the user is compatible with the browser that’s being used!


How Requests Get Turned into Responses

The basic structure of how Rails processes information is:

(Request) → Routes → Controller → View → (Response)

Let’s go through each of these pieces individually and see how they work together.

The routes.rb file is located within the config folder and tells the server where to go next given a particular web request.

Routes

A client request is first sent to the Routes file, which simply re-directs the server to look at a particular controller method.

Routes.rb lives within the config folder of a rails app. This file simply lists of all the acceptable client requests, and assigns it to a specific path to one of the Controller files.

Each command in the Routes file uses the structure:

get "/url_name" => "controller_name#method_name"

In the above example:

  • get is the type of client request,
  • url_name is the url that the client requested,
  • controller_name is the controller file that the request will be sent to, and
  • method_name is the name of the method that will be processed within the specified Controller file.

If a particular command or URL name is not listed under Routes, the user will receive an error message generated by Rails.

The controller is the workhorse of the operation! It does all the heavy coding and renders the html that the user will see.

Controller

The Controller files are filled with Ruby code that the programmer has written in order to customize the web app. These files are located within the app/controllers directory of a Rails app.

Once all the lines of code are run, the Controller then directs which html page to send back to the client.

The Controller file will look something like:

class Controller_nameController < ApplicationController
def method_name
# some code
render "html_name.html.erb"
end
end

In this example:

  • Controller_name and method_name are the same as the controller_name and method_name indicated within the Routes file.
  • html_name.html.erb is the file associated with the web page of the url that the client requested. This is file what the user expects to see when they submit a client request.

Note that under Routes, controller_name is lowercase, but since it’s a class in the Controller file, it becomes uppercase. Also note: an html.erb file is simply an html file with embedded Ruby code. However, web browsers can’t read Ruby, so Rails will convert the page to a pure html file prior to being sent to the client.

The view is what the user came for! It is what the user expects to see when visiting a website.

View

The html files that get sent back to the client are located under the app/views directory of the rails app.

Whenever a new Controller is created, Rails also generates an empty folder under Views where new html files are meant to be stored. The folder will have the same name as the Controller that it’s linked it. It’s up to the developer to make sure the html files get placed in the correct folder.

It’s important for new developers to understand this concept because if the html file is in the wrong directory, Rails will not be able to find it. The user would then receive an error message rather than the lovely html file that you’ve painstakingly built!

Adventures in Code

My journey as an up & coming software engineer and web developer.

Melissa Gonzalez

Written by

Aspiring Web Developer. Fitness Enthusiast. Foodie. Beer Lover. Triathlete. Soon-to-be Former Research Scientist.

Adventures in Code

My journey as an up & coming software engineer and web developer.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade