Rails Application Overview

1. Rails App Structure
2. Cases in Rails

 

---

 

In essence, a Rails app is a group of files that follow particular conventions and architectural styles (i.e. MVC, CRUD) in order to manage and serve applications built with Ruby. If you have seen the file structure of a Rails app before it may appear a little daunting, however we can usually get away with focusing only on the bits we will usually interact with:

/	The root of the application - everything in the app goes in here.
Gemfile	Lists all gems (Ruby libraries) used in the app. (The Gemfile.lock locks down versions of these gems).
app/	Contains most of our written code, housing the components of the MVC architecture.
app/assets/	Contains everything managed with the asset pipeline in previous Rails versions, such as CSS and JavaScript.
app/controllers/	The C of MVC: tells the application what to do with data. Organised in _controller.rb files.
app/javascript/	Contains manifests and custom code for everything managed with Webpack in newer versions of Rails, such as CSS and JavaScript.
app/models/	The M of MVC: tells the application how to store data. Organised in .rb files.
app/views/	The V of MVC: tells the application how to present data. .html.erb files organised in subdirectories named for their controller.
app/layouts/	Houses templates used in multiple views, including the master template.
config/	Contains files that tell our app how to behave.
db/	Houses the local SQLite databases and associated files.
db/migrate/	Contains files that create / update databases, following convention.
log/	Houses the logs of what our app has done.
node_modules/	Contains the third-party files downloaded by Webpack from the manifests in /app/javascript
yarn.lock	Lists all of the packages downloaded by Webpack and their versions.

To some people, it would appear that Rails works using magic, and the more zealous onlookers will be sharpening pitchforks and fetching kindling. However, we enlightened few understand the value of convention and rules, and this is the true source of Rails’ power.

As alluded to above, Rails follows the MVC (Model - View - Controller) design pattern where each of the components follows a naming convention in order to seamlessly interact with each other and provide a quick and easy customer journey without the endless configuration required by earlier application frameworks.
A brief description of this is:

1. We start with the End User on their browser. They navigate to the URL serving your app.
2. The application then consults its configured routes (conveniently housed in /config/routes.rb).
3. The route will inform the app which controller and action contains details of what it needs to do.
   -- (e.g. /app/controllers/things_controller.rb)
   In most cases, the action will direct it toward either:
   • A view containing the HTML the browser needs to display, stored in a directory named for the controller.
     -- (e.g. /app/views/things/show.html.erb)
   • A model for instructions on how to interact with one or more programmatic objects and therefore manipulate the corresponding database entries.
     -- (e.g. /app/models/thing.rb)
     • The application will then consult the database configuration to determine how and where it can communicate with the database.
       -- (config/database.yml)
4. The thing that the End User wanted to do is then complete with minimal fuss, and everyone is happy!

 

---

 

In addition to the naming of objects, cases are also used in Rails to bypass explicit configuration and masquerade as unholy sorcery. Cases denote what type of object is being defined or referenced, and the two used here are snake_case and CamelCase:

• Snake case is written all lowercase and words are separated with underscores.
  • We use snake case to define and reference methods when we write Ruby (do_a_rails_thing)
  • From within Rails, we also reference controllers and their actions with snake case (rails_things#do_a_rails_thing)
  • As seen when looking at MVC, we also name our files in snake case (rails_things_controller.rb)
• Camel case is written with upper- and lowercase characters, the former of which it uses to separate words.
  • We use camel case to define classes and modules in Ruby (class RailsThingsController)
  • When in Ruby only, we also use camel case to reference these classes and modules (RailsThingsController.do_a_rails_thing)

This all seems horribly abstract now, I know. We’ll soon get down to the nitty gritty of things and actually start putting all these things into action soon, I promise.

 
 

	|	Dev Environment Setup >
Back