đź’ŽRails File Structure Overview đź’Ž
One of the first things to familiarize yourself with when learning a new framework is its file structure. Today I would like to talk and give a short overview of the default files and folders generated by Rails. I always prefer the official documentation, please be sure to check out the resources below as well, and bookmark them for future reference if needed. Let’s get started!
Assuming that Rails is already installed on your machine, we need to run the rails new command to create a new Rails application. If for some reason, you do not have Rails on your machine, then we need to run the gem install rails. This command will install Rails globally, so you only have to run this once, and you will be able to use Rails from your terminal. More about critical / frequently used commands are here.
rails new your-app-name
Running the rails new command will create a new directory / folder that has a number of generated files and folders that make up the structure of a Rails application. A typical file structure looks like this:
As developers, we work with this file structure on a daily basis, so it is vital to become more familiar with the file system. Below is a breakdown for each directory. Also, check out this link to the official Ruby on Rails documentation to learn more.
app: The majority of your time will be spent working in this directory, so it is worth of getting more familiar with this section. This folder contains the controllers, models, views, helpers, mailers, javascript, channels, jobs, assets, etc. along with the rest of the core functionality of your application. Because the folder is the core directory and most of the application-specific code will come into this directory, I would like to focus on three major subfolders of this section: the Controllers, Models and Views.
app/controllers: This is where all the controller files go and store. The controllers connect the models, views, and routes. To be able to connect everything together, each route defined in the routes file must have a corresponding method in a controller. When a request is sent, Rails uses the routes file to determine which controller method to execute. The controller method then accesses data using the model, and uses that data to render the correct view. The naming convention for the controllers’ files is the pluralized model name + “_controller”. For example, if your model’s name is “User”, then your controller’s name in this file structure is “user_controller”. Bookmark this link, if you want to learn more about the controllers.
app/models: This is where all the models files go and stay. The model file is a Ruby class; it represents a corresponding database table and provides a number of methods allowing us to work and communicate with the database (database queries, data relationships, etc.). However, we can still treat it like a regular Ruby class and benefit from typical class functionality and methods. For example, a database table named “users” will be represented by the model “user”. By naming convention, the model name is the singular form (“user”) of the corresponding table in the database. More about the model controllers read here.
app/views: The third layer of the MVC design pattern is the views. The files related to the view functionality go into this subfolder. The purpose of the view is to render whatever it is sent from the controller. Types of those files are dependent on what kind of response our clients need, that could mean HTML, JSON data, etc. Check this out.
bin: This folder contains built-in Rails scripts that we most likely will never have to deal with.
config: As the name suggests the config folder contains all the application’s configuration files and number of settings that orchestrates the default behavior of your application such as the database connection, application’s routes, environment settings, a set of modules that are initialized when the application starts, language settings, etc. Here are a few, I think we need to pay attention to.
config/database.yml: This file defines database configuration. Depending on a database you use in your application, different configurations can be set for different environments. The Ruby on Rails provide a well written guide on how to configure a database.
config/routes.rb: This file defies all the routes of the application. In plain English, the route file re-direct incoming requests to the controller file and associated actions such as create, show, destroy, etc. In return, these actions / methods do some logic / manipulate data in the way we want. Check out this link on how to construct your own routes and interpret the code in config/routes.rb file.
config/environments: This folder contains the environment-specific configuration files for the following environments: development, test, and production. Configurations defined in application.rb file are available in all environments. Default environment files are development.rb, production.rb, test.rb, but you can add others, if needed. Refer to the official documentation to lean more about configuring your app’s environment.
config/initializers: This directory lists a number of files that need to be run during the Rails initialization process. Any *.rb file we create in this folder will run during the initialization automatically. For instance, if we need to declare a constant that needs to be available throughout your app, this place would be the right one.
.config.ru: This file is used by Rack-based servers to start the application.
db: Within the db folder we can find the current database schema, database migrations and seeds.rb files. This directory is another one that is frequently used and contains a lot of useful data. Let’s look into these subfolders.
db/schema.rb: This file is auto-generated from the current state of the database with the main purpose of documenting the final state of the current database. Looking at schema file gives you a quick sense and overview of the last created database and its definition. In addition, Active Record will update your db/schema.rb file to match the up-to-date structure of your database.
db/migrate: This folder lists all the available migrations you have created so far. We can consider each migration as a new version of the database. Any time we need to modify our database (add, delete or update columns, etc.), we write a new migration triggering the db/schema.rb file to get updated automatically. The migrations are stored as files, one for each migration in the form YYYYMMDDHHMMSS_create_products.rb
db/seeds.rb: It might be exhausting to populate your database with required records manually through a web form component, so this seeds.rb file is a great way to quickly send data in the application / database. We can use normal ActiveRecord methods for record insertion or utilize some Generating Randomized Data Tools such as Faker gem, for example. Finally, the data can be loaded with the rails db:seed command.
lib: The Rails guide says that extended modules for your application are stored in this directory. I would say that any custom code you want to use to enhance your application should be stored in this folder. Check out this post, if you want to dive into.
log: This folder holds and saves all the log files of your application. Rails automatically creates log files and store them in files “development.log”, etc.
public: The public directory contains some of the common files for web applications, HTML templates for HTTP errors, such as 404, 422, 500 and so on. When your app is up, this folder will be exposed as-is.
test: As the name of this directory suggests this holds all the test files for the application. By default, Rails will install the test suite in this directory. This is where all of your specs, test helpers, and test configuration files can be placed.
tmp: The name says it all! This is where the temporary files / data (like cache and pid files) are stored and is rarely accessed by developers. Most of the time, we do not need to worry about this directory, because it is controlled by Rails.
vendor: This folder holds the third-party code such as JavaScript plugins, CSS frameworks, etc.
Gemfile: The Gemfile is the file where all your application’s gem dependencies are declared in a structured way. A typical Gemfile has two parts — a source (a link to the external library, for example, RubyGems) right at the top of this file and a list of gems with versions. After any changes in this file, we need to run the bundle install command that will download all of the code dependencies in your application. As a side note, the bundle install command downloads the gems to one pre-defined directory on your system.
Gems (or libraries) are primary hosted by Ruby Community and can be found in the Ruby community’s gem hosting website. Individual gems can be installed by running the command gem install name-of-gem-you-want-to-install in the terminal. You can learn more about Bundler Gemfiles at the Bundler web site.
Gemfile.lock: While the Gemfile defines what dependencies need to be downloaded, the Gemfile.lock is the place where you download and store all those dependencies, including their associated versions. This file is generated by running the command bundle install. This file should not be edited or damaged in any way, messing around with the Gemfile.lock file can cause application bugs due to missing or altered dependencies. The Gemfile.lock file is similar to Package-lock.json file in React applications and serves the same role.
Rakefile: This file loads tasks that can be run in the terminal. The Rakefile requires application.rb and invokes Rails.application.load_tasks to loads all the rake files available / created in the lib/tasks folder. That is how you can run custom commands in a command line.
README.md: This file normally documents whatever steps are necessary to get the application up and running. We can place information on what the application does and other information, users might find useful.
Storage: This facilitates uploading files to a cloud storage service like Amazon S3, Google Cloud Storage, or Microsoft Azure Storage and attaching those files to Active Record objects. For a deeper dive, check out the link to Active Storage Overview.
.gitignore: Not everything you code and write in your application should be sent to the GitHub. Sensitive information such as passwords, database related data or available to everyone information, for example, libraries can be defined as “ignore” and not to be sent to the GitHub.
.ruby-version: This file displays the default Ruby version.
All right! We have learned a lot about a common File Structure of Ruby on Rails Application, and now we should be more familiar with the most critical folders of the Ruby on Rails Application such as app/controllers:, app/models:, app/views:, config:, db:, Gemfile: and Gemfile.lock. With this information at our disposal, creating Ruby on Rails applications will be easier and faster. Thanks for reading and keep the Ruby documentation handy too!
If you find this information useful, please feel free to follow me! Hope you enjoyed this short guidance on Ruby on Rails File Structure Overview, be strong and stay tuned!
