Skip to main content

43 Rails Application Structure

Episode 3 · July 2, 2014

A look into the files and folders inside every Rails application and how they fit together



Let's take a look at a Ruby application, and look at all the different files and folders inside of it so we can get an idea of what's going on.

rails new blog

we'll let it run the script to set itself up, it generates a whole bunch of files, and we can see here there is quite a few, so next it installs all the gems that it's going to depend upon which are like Rails itself and it's dependencies, so now that we have the blog created, we can open it up in our text editor adn take a look. The first thing that we probably want to take a look at is this file. This file basically says to load our environment file, and then run our Rails application, so this is called a rack up file, and a rack up file is basically saying that is wants to run a web server. Rack is a tool to allow you to build a web server really easily and that is what this file does, so you can pass this into something like unicorn or passenger, and it will know how to hand off requests that come into your website, so you don't have to run rails here, you can use Sinatra or anything that's Rack based and have a file, so what Rails does is that it loads Rails, and then runs your Rails application. How do we go do that?

When you come into the config file there's a few different files, the boot file is what loads up your Gemfile and then runs bundler to set up those gems. So this sort of boots up your application, make sure that you have all your dependencies, and Rails itself, and all of that. Inside your application.rb file, it loads that boot file and then requires rails, and it will also require your groups in your Rails application, so in development, you'll run the development group, and require those in production, you'll do the production ones and if you're testing, it will do those too.

Inside your application.rb file, you'll also have a little config block here, that allows you to set some global config items, so you might set your default language and locale for your application, or your default time zone, and you might set up some other things that we won't go into here.

That is just sort of the very highest level, and if you're taking a look into your environments folder, this is where your development environment config is, your production and your test. In development, it doesn't cache your classes, so it loads up your application every time, and it has a bunch of different things, so you can set it to raise_delivery_errors and a bunch of other things.

In production, it's similar, but also quite a bit different. They cache things so it's faster and compress your JavaScript and don't serve your asset files, because they want you to use NgineX or apache to do that and so on. That's your environments folder, and the per environment configurations basically.

Your initializers are a bunch of thing to initialize aspects of your Rails application. So if you're having cookies, inside your cookies we should probably story JSON for example. There's really not anything much to look at here, sometimes if you add a gem, you'll add an initializer like devise, and that will be used to configure devise as you load your application.

locales are somewhat obvious, you have your different translations by default. there's just "Hello World", and you can use these by calling them by name with the t method, and it will look it up inside of your locale, so if you add it, you'll be able to add Italian, and when the language or locale is set, to it or Spanish or whatever, you'll be able to add those, add a hello named one, and then put your translation in there, and that's really cool. But you probably don't need to mess with it by default. The locales/databse.yaml is very very simple, it has a bunch of different environments and you set up your database configs for these. So by default your Rails application pulls out this default one, and all of these share it and just override the database name in there, they're all using SQLite3, normally you're going to want to use postgreSQL or MySQL and add probably a username and password in there. So you can set it up if you don't want to inherit the default options, you can always put that stuff in your specific ones and delete this line. That's what I generally do. Production you'll have a different username and password and you don't usually want to save it in here, that's where the secrets.yaml will come in.

Your environment.rb file just requires the application so actually the rack up will load config/environment so then it goes to config environment which then goes to application and then requires all those which requires boot.rb and so on. So it has a little bit of a process that it goes through and each piece is very small, very specific to what it does and broken out. Your routes.rb is all the URL's and where they go in your application, so you'll be able to set these, they have a ton of examples, and that's where you define the URL's that you have in your app and where they go to.

This new feature of Rails 4 is this secrets.yaml, and this is a file that you can say in development we'll have these secret keys, in production we'll have some too but we're going to store those in the environment, so those environment variables that we talked about are important here because in production, you want that private keys, so maybe it's an API key or email server password, you want that to only stay on your production server and that's why you can set it up in your environment and then you don't have to keep it in your code base, so that's much safer that way.

Your bin directory has a few stubs basically for these executables, so the Rails executables, you can type bin/rails and then execute rails with this tool, so load ruby, and then try to load spring which allows your applications to run a little faster, and then it loads application and boot and runs your rails commands. So these are basically little stubs for your executables that allow you to keep that stored inside of your rails application, so if you want to tweak this and add pry or something, you could do that too. Your app is where all of the code goes, your app/assets is where all of your images, JavaScript’s and stylesheets go. The controllers folder is for the business logic, generally where do we send this request to and where does it go, kind of organizing where things happen. concerns are a way of pulling out some of the repeated stuff and controllers. helpers are for your views, so when you're displaying someone's name, you can take their first and last names and add them together, make a little helper method to accomplish that there.

Mailers are of course for your mailers, so if you want to send an email, you'll define the way that that happens in your email templates will go inside of views for those. Models are your database tables and database models as they call them, concerns here are the same thing, so if you have a concern that is shared between several model so they do similar things, you can pull it out into a concern. Views, you have a layouts folder which is for your general layout of your webpage, and that will yield to the other views that you have, so when you have like a sign in page, it will use the same layout and we'll just put the sign in box in the middle of the page, for example. So you can make more layouts and have different sort of styles of the way your application looks.

Your db folder will have just seeds by default, and these are a way for you to add default data into your database so you could create some cities by default, or mayors, these are just examples, but when you also create database tables there will be a migrations folder in here that stores those, this folder will keep track of all the changes you make to your database and allow you to be able to replicate it and move back and forth between them.

The lib folder is some libraries that you may or may not use, a lot of Rails applications that are big will use them, so you can have these extra tools to help you build your rails app.

The logs folder doesn't have any logs in it right now but when you run your Rails server, it will store your log files in there, so that you can see what's been happening.

Your public folder are these public files, so when something goes wrong, or you hit a URL that doesn't exist, you can have these static files that are available that won't get compiled through the asset pipeline, so they'll just get serve directly and that's it. So the robots.txt one for the search engines is a good example. You probably don't need to mess with this ever or compile it or anything so you just put it in there and that's how it will work.

Your test directory has a bunch of stuff for testing your controllers, creating fixtures so you can test them, test for your helpers, integration test, mailer test, model test, and a helper that helps you set up your testing environment.

Your tmp folder is for when you compile your assets and just temporary files that Rails needs to create once in a while.

Your vendor folder, view something like bootstrap for example, you could put bootstrap stylesheets and JavaScripts inside of here. vendor is basically for stuff that is third party that you want to use in your Rails application but you're never going to change it, so you don't really want to keep it inside of your app folder. And last but not least we have your Gemfile, it declares that we're using Rails and sqlite3 and all of these gems, just our dependencies takes this information and then writes down the specific versions and all the dependencies for each of those that you'll use, so this file is really important because when you test that your application works on your computer, when you put it on your server, it will use the exact same versions, so that you know that your app is going to work is going to work on your server, and that’s really important because you don't want to deploy it to production and break things, so your rack file is basically going to load your application and provide you some tasks that you can run from the command line, so you can run your migrations with rake, and this just loads up rake and defines how to work so there's really not a whole lot to it, you may or may not tweak this at some point but that's about it.

Your README of course is just a stub for how your README should look, if you're going to use Rdoc. I usually rename this to .md so I can use Markdown and then change all of this to keep track of how you create your database, and here's how you run your tests and so on. So there's not a whole lot to a Rails application but there’s quite a few little things that you need to dive into and be familiar with. A lot of people don't edit the application.rb or the environment.rb or especially the, people rarely edit that, so don't be afraid of it. It's just running regular ruby code and loading up these files and running these commands, so none of this is special, all of Rails is just ruby code, so don't be afraid of any of these things of fiddling with them because it's not bad to do that. This is your code so you should be okay with editing any of it. So that's a good explanation of the directory structure and what they are, and what they all kind of do in a Rails application.

Transcript written by Miguel


Gazi Tarique Mahmud (10 XP) on

Great one ever explain like you...thumbs up!!

Dana Nourie (930 XP) on

This was great! I almost didn't watch it, but you covered files and directories I didn't understand. Thank you!

DevinHe on

Thank you for your great introduce.Now i also understand how the Rails works more clearly.

Login or create an account to join the conversation.