- Read Tutorial
- Watch Guide Video
You have built out a Rails app and have added a completely functional feature to your app with the creation of your own blog. Considering the amount of code that had to be written to generate that functionality, it’s impressive that you could do so much in such a short amount of time.
In this deep dive section, we're going to take a step back and discover exactly what Rails does when it runs the generator by diving into the code it writes. Although we walked through the file system and took a look at the files created for us, this will be a deeper look. We'll also discover some options we can choose for building our applications.
If you remember, when we built our portfolio application we used some custom parameters. We chose not to build out the testing environment and we installed the alternate postgresql database. This guide will show you what is going on behind the scenes of the app generator and will take a look at some of the changes that would occur to our app if we used some of the other parameters instead.
Let's go to our terminal and navigate to the desktop folder.
To recap, the command to reach our desktop is cd ~/Desktop
I'm in the desktop folder because I want to generate a few applications. We won’t continue to build them out, so we can create them here and easily delete them. By following along you will be able to see exactly what is being created for us in the Rails generator process.
Help Menu
To bring up the Rails help menu type the command rails -h
This command will bring up all of the options that are available to us.
This may seem overwhelming, but if we look at each item one at a time it’s all pretty straightforward.
Usage
The first item in the help menu is usage.
This is the same line we used to create our app: rails new App_Path [options]
APP_PATH is the same as app name, which in our case, was DevCampPortfolio. It's called APP_PATH because sometimes you may want to put your app in a specific location.
For example, you can type rails new /Testdir/my_app
This will create an app called "my_app" in a directory named Testdir. With this command you don’t need to be in the current directory at the time of creation.
Options
Now, we'll get into the options. The first option -r is for the Ruby path. This is not something we'll have to worry about as we utilize RVM. You would only use this if you wanted to see how your app behaved while running it on a different version of ruby. RVM makes this quite simple, so for our purposes we can do without this option.
Templating
Next is -m. If you look at the information after the # symbol you will find a description of the option.
It states -m gives the path to an application template. It can be a file system path or a URL.
Just like with any templating process, this option helps you to customize the generation of your app. For example, let's say, you work for a company and it has many preconceived configuration files such as communications with your company's private network or configuration items for connecting with an API. By passing in -m or -- template=TEMPLATE you can pass in a link to the template and it will build those items in for you.
I've used this option to connect to rspec instead of the default test system. If you've never heard of rspec, don't worry, as it's just a custom library for testing. The important thing to keep in mind is that the template option not only saves you time, it allows you to configure your app to your custom processes. This is helpful when doing repetitive tasks.
The Database Option
The next option is, which we used when creating our app, is for choosing your database.
You can also use -d or --database=DATABASE The capital words denote the value you'll have to type in. In our case we used --database=postresql
The description lists the different database options that you can use such as mysql or oracle or jdbc. The default is ‘sqlite3’, so if you don’t specify an option that is what will be used.
It is important to use this option at the time of creating an app because rails will create all your settings for you. It can be frustrating to change the database later, so always remember this step when you are creating a new app.
Javascript Customization
The next option is -j, which is the javascript library you'll use for the application. The default is “jQuery”. If you'd like to use something else, like Angular you can choose it with this option. Personally, I like to use jQuery for Rails. I’ve used the jQuery library for years and feel and that is great for working inside of Rails, especially for what we are going to build.
Options to Skip Items
The next set of actions allow you to with skip particular items.
--skip-gemfile, the first on this list, allows you to skip the gemfile. This is something you would use if you weren’t using gems in your application or if you were using something other than bundler. It would be very rare to use this command.
Skip Bundle
The second item in this section allows you to skip bundle install. Let's try it this one out. Notice that there are two ways to use this command -B or --skip-bundle. We will try this out with the short version.
Type the command rails new my_fast_app -B into your terminal.
Notice how quickly your app is created. This command creates our app so much faster because in a standard app creation, Rails runs the bundle install command by default. Bundle install finds all the code libraries present in the gemfile and pulls them into the application for us. With our choice to skip this action we simply created a base application.
This option can be particularly useful when you want to add items to your gemfile. If you used a template you wouldn’t go this route because everything you wanted would already be a part of your build. However, if you knew you needed to add a couple of gems to your Gemfile after the app was created, you could choose this faster option.
After the basic build you would open your app with sublime and add the gem, such as ‘devise’ (a gem for authentication) to your gemfile.
After saving you would go back to the terminal and run bundle install. This would save you time because you would not have to run bundle install twice.
Skipping Git
Moving on, let’s check out our options again with the command rails -h.
The next one we will discuss is -G which will skip the .gitignore file. This can be useful if your client doesn't want to use Git or has chosen a different version control system. This would be decided on an app by app basis.
Next is, --skip-keeps. This is something we'll try out.
Let’s create an app called no_keeps with this command: rails new no_keeps --skip-keeps
In a previous guide about the file system we discussed the benefit of .keep files. Many version control systems will not track empty directories, but will simply delete them. When you want to push up an empty directory to GitHub or Bitbucket, the .keep files will allow you to save that empty directory.
This option will ask the system not to create any .keep files, so empty directories are deleted by GitHub. If you open this application in sublime, you'll see that there are a few empty directories such as lib/assets and lib/tasks. Neither of these directories would be pushed up to GitHub. Honestly, I don't think I’ve ever had a situation where I needed to run this command. The .keep files take up no space, and they are very useful when working with GitHub, so this may not be something you would want to use. However, it is good to know the option exists, and would work should you need it.
Skipping Base Rails Setup Items
Next is -M which skips the action mailer. You can skip this if your system doesn't need to send out emails.
Similarly, use -O if for any reason you don't want to use "Active record" to connect to the database, or your models.
The next one is -P, which is to skip the Puma server. Puma is a very powerful web server that ships with Rails 5 by default. This is actually great because the earlier versions of Rails had a really slow web server, and we had to change it to "puma" or any other fast web server when we wanted to push to production. Again, if you want to use different web server, this option is handy.
Another option is -C which skips action cable. Action cable is new to Rails 5 and allows you to have a direct non-blocking I/O. If you're application is going to have a chat feature, then action cable makes that possible. In our portfolio app, we will be working with action cable. However, a lot of apps do not need this capability, so it’s good to know you can use this option to skip it.
Next, you can choose to skip sprockets, spring and the listen gems. Sprockets help the Rails system run along with Spring and Listen. They listen for file changes and give you the capability such that you no longer have to close the rails server and start it back up again. In previous versions of rails Spring was somewhat buggy, but it seems to function better in Rails 5. If you don't need it, use —skip-spring to bypass it entirely.
Skipping Javascript
Next, if you don't want any javascript at all for your application, use -J. Take note, using -J will skip not just javascript, but also turbolinks. Turbolinks is essentially Rails way of working like a front-end MVC application such as angular. So, if you want to keep javascript, but not turbolinks, then you can use the specific command --skip-turbolinks.
Skipping Tests
This next option is one we used when creating our portfolio app. When you use -T, it will skip the installation of all test files. If you open the my_fast_app in sublime, you'll see that it has a folder called test filled with files. In this course, we're not going to go in detail with testing or testing-driven development (TDD).
It is best to use this option if you are going to use a different testing framework or you are not going to use tests at all. I skipped the test environment completely in our app because I don't like to have any extra code that we won't be using. You always have the ability to come back and install a test library later, so skipping it in the beginning is not an issue that would cause problems later on
Choosing the latest version of Rails
The “dev” and “edge” options are for installing different versions of Rails. By default our system installed Rails 5.0.1, which is the most current stable version of Rails. However, if you want the edge version, then you can install it with the command --edge. This will set up the application with the gemfile pointing to the Rails repository which will pull the very latest version of Rails.
Going with this option isn’t always the safest because many of those edge and development versions are like that for the reason that they are still being developed. In general, we use the most stable versions of Rails for stability. However but if you want to explore and see what Rails is developing, feel free to use one of these other options.
The next section is runtime options. I recommend you play around with them, but these are items we are not going to get into.
The API Option
The last item we are going to discuss in this guide is the API option. This is very important for a Rails developer to know about. There will be occasions when you will want to develop a Rails app, but you won't want to create a front end.
One example would be building a pure Rails API. No user is going to come to your application, so you would have no need of a front end. When you build a pure API you are setting up a connection to a set of databases and algorithms that you have built. Likewise, if you're building an "angular" app and want to use Rails as a backend, there is no need for a Rails front end.
In such cases, you'll use the option --api
Let's see what happens when we use it. Type: rails new my_api --api -T
I am going to run bundle install on this so you can see what happens with the generation process.
Now, cd into your app with the command cd my_api
Now run rails db:create && rails db:migrate
This will create and migrate the database for us.
Next, we'll use scaffolds to create a post feature using the command: rails g scaffold Post name:string body:text
What I really want you to understand is that when you use --api, Rails will generate a completely different set of scaffolds.
After generating the scaffold you will need to run rails db:migrate again. Notice no view files were created.
Open this app in sublime, you'll see that it is a much more lightweight application that a complete build would be.
Go to the app/views/layouts folder, and you'll see that all you have is the layout for the mailer.
You do need a mailer so you have the capability to send an email from your app. Other than that, in terms of the scaffold for the Post we generated, there are no other view files created because this is an API only application.
When you go to the app/controllers/posts_controller.rb, you'll see that our scaffold created a controller with all the typical actions. However, the method has a call to specifically render json.
All this is because it's an API-only application.
This is one of the more important options we have when building our Rails apps. As a Rails developer there is a good chance you will need to build a pure API. This —api option is a good way to build one quickly and efficiently.
Rails Source Code
Before we end, I want to show you the Rails source code
Due to the fact that Rails is an open-source application, we have access to look at all the code that powers the Rails system.
The linked file is the application base for the generators. All the magic that happens when you run rails new, is coming from this code.
You can see there is a module called Rails (line 10) inside of that is Generators (line 11) and then it has an Appbase class (line 12). You can see the custom elements we talked about when setting up a custom DATABASE (line 277). This declares the full list of database choices we discussed. When you passed in the option:
--database=postresql the generation process chose it from this file and built it for you.
Likewise, each option we talked about has its own respective set of code options, and generation processes associated with it, compiled in this file.
If you're new to Ruby or Rails and this code is a little confusing, don't worry, as this very advanced code that was written by some of the most talented Ruby and Rails developers in the world. This is just to give you an idea of the code that runs to create your Rails application, and how the different options are programmed into it. As you continue to become a more advanced Ruby developer, this type of code will make more and more sense.
For example on line 277 you can see they created a method called the gem-for-database
This method simply looks at the options you add when you run the Rails new command. It asks, did they declare a database? If yes, which one? If it was the ‘postgresql’ option then Rails would add the ‘pg’ gem (followed by the version number) to the gemfile. If you go look at your portfolio app gemfile you will see this ‘pg’ gem listed there. That process was made possible by this one line of code! Just keep in mind that looking at the source code can help you to understand how Rails generation process is working for you.
You should now have a good understanding of how to create a Rails app by passing in the options that will customize the application to your needs.