Introduction & App Generation
Let's take a look at a Rails application and look at all the different files and folders inside of it so that we can get an idea of what's going on. So if we create a new Rails app, I'm just going to call it blog, and 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 its dependencies. So now that we have the blog created, we can open it up in our text editor and take a look.
The Rackup File (config.ru)
The first thing that we probably want to take a look at is this config.ru file. So this file basically says let's load our environment file and then run our Rails application. This is called a Rackup file, and a Rackup file, it's basically saying hey, we want 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 in to your website to your application. So you don't have to run Rails here, you can use Sinatra or anything that's Rack-based and have a config Rackup file.
Booting the Application (config/boot.rb & application.rb)
So what Rails does is loads Rails and then runs your Rails application. So how do we go do that? Well, when you come into the config file, there's a few different files. The boot file is what it loads up your Gemfile and then runs Bundler to set up those gems. So this sort of boots your application, makes sure you have all your dependencies and Rails itself and all of that.
Inside your application file, it runs your—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, we'll do those too.
Inside the application file, you 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. So that is just sort of the very highest level.
Environment-Specific Configuration
And if you're taking a look into your environments folder, this is where your development environment config is, your production, and your tests. So in development, it doesn't cache your classes, so it reloads your application every time and it has a bunch of different things. So you can set it to raise delivery email 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 Nginx or Apache to do that, and so on. So that's your environment folder and their per-environment configurations.
Initializers and Internationalization
Basically, your initializers are a bunch of things to initialize aspects of your Rails application. So if you're having cookies, well inside your cookies, we should probably store JSON, for example. There's really not anything too much to look at here. Sometimes if you add a gem, you'll add an initializer like Devise has one, 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', then 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. So that's really cool, but you probably don't need to mess with it by default.
Database, Routes, and Environment Loading
So we've talked about the application, the boot. Your database.yml 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. So 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, so that's where the secrets.yml will come in.
Your environment file just initializes your Rails application, requires the application. So actually the Rackup will load config/environment, so then it goes to config/environment, which then goes to application, and then requires all those, which requires boot, and so on. So it has a little bit of a process that it goes through, and each piece is very, very small, very specific to what it does and broken out.
Your routes is the different URLs 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 URLs that you have in your app and where they go to.
Secrets and Executables (secrets.yml & bin/)
This new feature of Rails 4 is the secrets.yml, and this is basically a file that you can say, in development we'll have these secret keys and production will have some too, but we're going to store those in the environment. So those environment variables that we talked about are here because in production you want that private key. 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 in the environment and then you don't have to keep it in your codebase. So that's much safer that way.
Your bin directory has a few stubs basically for these executables. So the rails executable, you could type bin/rails and then execute Rails in with this tool. So it'll 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 like 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.
The app Directory: Core Application Code
Your app is where all of your code goes. app/assets is where all of your images, JavaScript, and stylesheets go. Your controllers folder is for the business logic generally, like where do we send this request to and where does it go? You're kind of like organizing where things happen. Concerns are a way of pulling out some of the repeated stuff in controllers.
Helpers are for your views. So when you have your 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 for, of course, your mailers. So if you want to send an email, you'll define the way that that happens and your email templates will go inside of views for those.
So models, before you skip ahead to views, 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 models, 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 then 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.
The Database Directory (db)
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. So the migrations 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.
Supporting Directories (lib, log, public, test, vendor)
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.
Your logs folder is—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 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 served up 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 to work.
Your test directory has a bunch of stuff for testing your controllers, creating fixtures so you can test against them, test for your helpers, integration tests, mailer tests, model tests, and a helper that helps you set up your testing environment.
Your temp folder is for when you compile your assets and just temporary files that Rails needs to create once in a while.
Your vendor folder, if you used something like Bootstrap, for example, you could put Bootstrap stylesheets and JavaScript inside of here. Vendor's 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, you usually put it in your vendor folder.
Key Project Files (Gemfile, Rakefile, README)
And last but not least, we have your Gemfile. It declares that we're using Rails and SQLite and all of these gems, just our dependencies. Your Gemfile.lock 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 your app's going to work on your server. And that's really important because you don't want to deploy it to production and break things.
Your Rakefile 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 it'll 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, 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 just change all of this to keep track of, hey, here's how you create your database and here's how you do run your tests, and so on.
Final Thoughts and Encouragement
So there's not a whole lot to a Rails application, but there's quite a few little things that you need to like dive into and be familiar with. A lot of people don't edit the .rb or the environment.rb or especially the config.ru file. No one, very rarely edits 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 they're not—none of this is special. All of Rails is just Ruby code. So don't be afraid of any of these things or 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 all kind of do in a Rails application.
