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

Comments

Post a Comment

Popular posts from this blog

[ToDoList] Basic Pages

Image
Well that was fun. However all we’ve really done is spooked someone called Bob, without actually creating anything remotely resembling a web application. Let’s rectify this and create some pages one would normally find on a website; a Home page and an About page. Home & Away About Helpful Links [Insert Beatles Reference]     Because we already learned a bit about MVC, we know that we will need a controller and at least one view to display these pages (we won’t need to worry about models until we’re handling real data). As before, we’ll need to add a route configuration so Rails knows where to go, too. Rails provides a fair bit of magic to streamline this process in the form of generators . However, because we’re learning, we’re going to do this manually for now and learn what this magic entails, so we can appreciate it more later. We already created a PagesController in the...
Read more

New Rails Apps with Docker Compose

Image
Following on from the Docker & docker-compose guides, it is possible to use docker-compose to build a Rails application that uses a PostgreSQL database without even installing Ruby on your local machine by instead using containers ! This becomes a very useful option to have if you work from many different workstations and don't want to ensure they are all equipped with the correct Ruby and Rails dependencies, or if you wish to use a version of Ruby / Rails not supported by your operating system (for example, Ubuntu 20.04 only allows provides up to Ruby 2.7 in its apt cache). In fact, Rails 7 added native support for Docker, such that it generates almost all of the default files we need for us! This comes with its problems and, I won't lie, updating this post to work with Rails 7 (it was previously written for Rails 6) has been a colossal pain and features a bit of hackery. However it is ultimately a good thing, and having ...
Read more

[ToDoList] Building the App

Image
The new Generator The Rails Development Server     So we have now learned some theory about Rails and set up our development environment with the required packages and version control prerequisites. I think that’s enough preamble, let’s get developing! The next few sections will involve creating a funky little web app that contains a To-Do list that we can add, remove and edit entries from. We saw a very small snippet of the extensive file structure that Rails uses in the first section. If you thought you’d be constructing the longest mkdir -p command in the observable universe to get all of this set up, you will be pleased to know (as I was) that our first utilisation of Rails magic will be to get Rails to generate all of this for us! Feel free to set up a projects directory on your dev machine, or you can just use your home dir if you’d prefer. Whatever you choose, change into this dir n...
Read more