On the Rails — an intro to how Ruby on Rails works with the Web

You’re new to web development, and you want to build a web app. You might start with Ruby on Rails, which is an established framework for building websites. Technically, it’s a software library of a LOT of Ruby code that others have written — making it a gem! See my post on gems to learn more about neatly packaged Ruby code.

When getting a good sense of how Rails works, I think it helps to understand the basics of the big picture, so let’s back up a level and talk about how the web works. And I do mean web, not Internet. If you thought they were the same thing, you’re certainly not alone. At the most basic level, the difference is that the Internet is the physical connection of computers to one another (hardware), while the web is the software. In the diagram below, you can see that the whole world is criss-crossed by a network of fiber optic cables that are actually largely underwater. It’s tempting to think of the “cloud” as in the sky somewhere, perhaps using satellites, but nearly all of our basic internet connection lives on the ocean floor.

Fiber optic cables connecting us all to the internet

The web, on the other hand, is a collection of rules for how computers communicate with each other. The web is probably the most commonly used Internet service, and the way it works is through protocols. There are lots of different protocols that govern how the web works, such as IP (Internet Protocol — every computer has an “address”), TCP (Transmission Control Protocol — how connection is established, and data is transmitted), and the one we’re mostly talking about today: HTTP (Hypertext Transfer Protocol).

Hypertext Transfer Protocol

Servers are computers directly connected to the internet (think: cables). They have a unique IP address that allows users to access them to get information. When we type in “www.google.com” into the browser URL, we are using the domain name, an alias for Google’s server’s IP address, which is actually a series of numbers.

The computer you’re using to read this article also has an IP address that the servers will use to send information back to you. If you’re curious about your own IP address, you can type “What’s my IP address” into google.com, and it’ll tell you!

Your browser (e.g. Chrome, Firefox, Safari, etc) is known as a client. The way your browser gets your requested web pages to load is via a series of HTTP requests to servers.

Typical HTTP request/response cycle

When the server receives the request (which, surprisingly enough, comes in a readable textual form), it finds the requested webpage and sends it back to the client. If it’s not able to find the specific requested page, it’ll send back an error message. It always has to provide a response of some kind.

To remove a layer of mystery, here’s what the HTTP request looks like if I type google.com in my browser.

Accessed through Chrome developer tools

To break that down:

• Request URL: the domain name/alias of the Google server address.
• Request Method: the most frequent methods that are used are GET, PUT, PATCH, POST, DELETE. They all refer to operations that will be performed. In this case, I just wanted the Google page to display, so typing in google.com initiated a GET request.
• Status Code: information on the success of the request. If you were to receive status code 404 for example, it would mean that the page was not found. (https://httpstatusdogs.com/ for cute dogs and status codes)
• Remote Address: the server IP address.
• Referrer Policy: we’re not going to dive deep into this but it’s the information that will be sent with the request.

Now that we know what an HTTP request looks like, we can talk about the MVC — Model, View, Controller pattern.

• The Database is where all your data is being stored. It’s the tables you’ve built out (usually corresponding to your Models) that store the objects’ relationship as well. It’s accessed through SQL queries.
• The Models are the objects you’ve built for your app and ActiveRecord allows the Models to interact with the database by saving, deleting, and updating records. (Visit my fellow cohort mate’s guide to ActiveRecord for an extra overview.) Models also control app validations, and custom logic for your objects and application.
• The Routing section is the aircraft marshal of your web app. Routes interpret the HTTP request and direct it accordingly.
• The Controllers interact with their associated Model and then pass that information to the View, which is what is rendered back to the browser for you to see on your screen.

Back to the diagram. You start inside your browser, where you type in (for example) icecreamflavors.com, which I built using Rails and is being hosted on a web server. This is an HTTP GET request.

In Rails, I have built out a series of routes (the yellow box), which will read that request and determine which controller to send it to, as well as which action to call on within the controller. Typically, each Model will have its own controller with a number of actions in each, and often there are additional controllers for more abstract things like the “session.”

In this particular case, typing in icecreamflavors.com should bring you to the homepage for all the ice cream flavors. The route will direct you to the controller for ice cream flavors, where the action for seeing all flavors is called “index.” My index method will call on the IceCreamFlavor Model, which will retrieve all the flavors from the database and give them back to the controller.

The controller is then able to pass that information to the View page for viewing all ice cream flavors, which is what you will see in your browser.

There is an additional thing to note that makes Rails particularly user friendly. Rails is a strong believer in the concept of “convention over configuration.” What that means is that Rails makes a lot of mundane decisions for the developer. For example, when you type rails new, the entire file structure of an application is built out for you. Controllers will always live inside the controllers section of the app folder. The index action in the controller will render the index view page even if it is not explicitly coded to do so by the developer of that specific application.

Taking away a lot of individual decision making on the basics allows developers to easily jump in on other projects without being completely lost. The docs for Ruby on Rails are famously very good, and I highly recommend this section if you want to learn more about convention over configuration and the “omakase” way of developing applications.

I hope this article helped you better understand how Rails works in the grand scheme of the web, and you’re now off to build your own websites :)

Happy coding!