As you generate controllers for your application, Rails also generates a corresponding JavaScript and CSS file in the app/assets/javascripts and app/assets/stylesheets directories. Rather than link to each of these files separately in your application, Rails uses a manifest file. As mentioned in Chapter 5, a manifest file is a list of other files needed by your application.

Manifest files use directives, instructions specifying other files to include, in order to build a single file for use in the production environment. The require directive includes a single file in the manifest. The require_tree directive includes all files in a directory. The require_self directive includes the contents of the manifest file.

To see an example, open the default CSS manifest at app/assets/stylesheets/application.css:

  /*
   * This is a manifest file that'll be compiled into application.css,
   * which will include all the files listed below.
   *
  --snip--
   *
➊  *= require_tree .
➋  *= require bootstrap
➌  *= require_self
   */

This file first uses the require_tree . directive ➊ to include all CSS files in the current directory. It then includes the Bootstrap stylesheets using the require bootstrap directive ➋ you added in Chapter 9. Finally, the require_self directive ➌ includes the contents of this file below the comment block. Currently, nothing appears below the comment block.

The asset pipeline searches for assets in three different locations by default. You know about one of them already: The app/assets directory is used for CSS, JavaScript, and image files owned by your application.

The lib/assets directory is for assets needed by libraries you have written. Because you haven’t written any libraries yet, this directory is currently empty. The vendor/assets directory is for assets created by third parties, such as code for JavaScript plug-ins and CSS frameworks.

Ruby gems can add their own directories to the list of locations that the asset pipeline searches. You can see this in the JavaScript manifest at app/assets/javascripts/application.js:

  // This is a manifest file that'll be compiled into application.js,
  // which will include all the files listed below.
  //
  --snip--
  //
➊ //= require jquery
  //= require jquery_ujs
  //= require turbolinks
➋ //= require_tree .
➌ //= require bootstrap

This file uses the require directive ➊ to include the jQuery, jQuery UJS, and Turbolinks libraries that are part of the jquery-rails and turbolinks gems included in your application’s Gemfile.

It then uses require_tree ➋ to include all JavaScript files in the current directory. Finally, it requires the JavaScript files ➌ needed by the Bootstrap CSS framework.

You won’t find jquery, jquery_ujs, turbolinks, or bootstrap in the vendor/assets/javascripts directory. Instead, the gems that provide these files have updated the asset pipeline search path to include their own directories.

You can see the complete list of asset pipeline search paths by entering Rails.application.config.assets.paths in the Rails console. This statement returns an array of paths. In this list, you should find paths such as jquery-rails-3.1.0/vendor/assets/javascript, turbolinks-2.2.2/lib/assets/javascripts, and bootstrap-sass-3.1.1.0/vendor/assets/javascripts.

As you’ve seen, CSS and JavaScript files are served as separate, uncompressed files in the development environment. Your social media application is serving 31 separate CSS and JavaScript files according to the server output. An asset pipeline configuration called debug mode controls how assets are handled in each environment.

In the development environment, debug mode is turned on. That means the files referred to in the CSS and JavaScript files are served separately, which is useful if you need to debug an issue with a file using your browser’s development tools.

If you want to force assets to be combined and preprocessed so you can see how they are served in the production environment, you can turn off debug mode. Just change the value of config.assets.debug near the bottom of the development environment configuration file config/environments/development.rb:

config.assets.debug = false

When debug mode is off, Rails concatenates and runs preprocessors, such as the CoffeeScript or Sass compiler, on all files before serving them. Restart the Rails server after modifying this file, and then check the server output in your terminal to see the difference:

  Started GET "/login" for 127.0.0.1 at 2014-03-16 20:38:43 -0500
  Processing by SessionsController#new as HTML
    Rendered sessions/new.html.erb within layouts/application (1.5ms)
  Completed 200 OK in 5ms (Views: 4.5ms | ActiveRecord: 0.0ms)

➊ Started GET "/assets/application.css" for 127.0.0.1 at ...

➋ Started GET "/assets/application.js" for 127.0.0.1 at ...

Only two files (➊ and ➋) are served now—the CSS and JavaScript manifest files. This setting can actually slow down page loads in development because the files are combined for every request, so change config.assets.debug back to true before continuing.

In the production environment, you should precompile your application’s assets and serve them as static files by your web server. You can precom-pile assets in several ways. When you deployed your blog to Heroku in Chapter 6, you precompiled assets during deployment. Rails also includes a rake task to precompile assets.

The rake task compiles all files from your CSS and JavaScript manifests and writes them to the public/assets directory. You can precompile assets for the production environment with the following command:

$ RAILS_ENV=production bin/rake assets:precompile

During precompilation, an MD5 hash is generated from the contents of the compiled files and inserted into the filenames as the files are saved. Because the filename is based on the contents of the file, you can be sure the correct version of the file is served if you update a file.

For example, after precompilation, the file app/assets/stylesheets/application.css might be named public/assets/application-d5ac076c28e38393c3059d7167501 838.css. Rails view helpers use the correct name automatically in production. You don’t need the compiled assets for development, so when you’re finished looking at them, remove them using the assets:clobber rake task:

$ RAILS_ENV=production bin/rake assets:clobber

This command deletes the public/assets directory and all of its contents.

In Chapter 15, you’ll learn how to deploy your application to your own server using a program called Capistrano. You can configure Capistrano to precompile assets automatically during deployment just as you did when you deployed the blog to Heroku.

Turbolinks is on by default in new Rails applications. You’ve been using it without even knowing since you built your first application in Chapter 2. You can see it working by watching the output from the Rails server. Go to http://localhost:3000/ in your browser and check the output in your terminal:

Started GET "/" for 127.0.0.1 at ...
Processing by PostsController#index as HTML

--snip--

Started GET "/assets/bootstrap.js?body=1" for 127.0.0.1 at ...

Started GET "/assets/application.js?body=1" for 127.0.0.1 at ...

After the GET request for the posts index page, the browser fetches all of the CSS and JavaScript files needed by your application. Now click a link such as New Text Post on the index page and check the output again:

Started GET "/text_posts/new" for 127.0.0.1 at ...
Processing by TextPostsController#new as HTML
  User Load (0.2ms) SELECT "users".* FROM "users"
    WHERE "users"."id" = ? LIMIT 1 [["id", 7]]
  Rendered text_posts/_form.html.erb (2.4ms)
  Rendered text_posts/new.html.erb within layouts/application (3.3ms)
Completed 200 OK in 38ms (Views: 36.5ms | ActiveRecord: 0.2ms)

The browser only makes a GET request for the New Text Post page. It does not fetch the CSS and JavaScript files because they are already loaded in memory. Finally, click the Back button in your browser.

This time there is no output in the terminal window. The index page was cached in the browser and no requests were sent to the server. Turbolinks caches ten pages by default.

If your application includes JavaScript code that uses jQuery’s ready function to attach event handlers or trigger other code, the JavaScript needs to be modified to work with turbolinks. Because turbolinks doesn’t reload the entire page when a link is clicked, the ready function is not called.

Instead, the page:load event is fired at the end of the loading process. You can see this in action by adding the following CoffeeScript code to app/assets/javascripts/posts.js.coffee:

  --snip--

  $(document).ready ->
➊   console.log 'Document Ready'

  $(document).on 'page:load', ->
➋   console.log 'Page Load'

Unfortunately, CoffeeScript is beyond the scope of this book, but you might recognize what this code snippet does if you’re already familiar with JavaScript. It prints “Document Ready” ➊ in your browser’s JavaScript console when the page first loads, and “Page Load” ➋ when you click a link that uses turbolinks.

Because you aren’t currently using $(document).ready() to trigger any JavaScript code, you don’t need to worry about this right now. But you should revisit this section if you ever start using the ready function.

Make sure your server is running, and keep an eye on your terminal output as I walk you through a few examples. Be sure you are logged out of the application before you start. First, browse to the login page at http://localhost:3000/login and check the server output:

Started GET "/login" for 127.0.0.1 at 2014-03-18 18:58:39 -0500
Processing by SessionsController#new as HTML
  Rendered sessions/new.html.erb within layouts/application (2.0ms)
Completed 200 OK in 12ms (Views: 11.8ms | ActiveRecord: 0.0ms)

This page doesn’t produce any SQL queries.

Now log in to the application:

  Started POST "/sessions" for 127.0.0.1 at 2014-03-18 18:59:01 -0500
  Processing by SessionsController#create as HTML
    Parameters: ...
➊   User Load (0.2ms) SELECT "users".* FROM "users"
      WHERE "users"."email" = '[email protected]' LIMIT 1
  Redirected to http://localhost:3000/
  Completed 302 Found in 70ms (ActiveRecord: 0.2ms)

This page produces one SQL query ➊ as Rails loads the user matching the email address you entered on the previous page. The create method in SessionsController uses this record to authenticate the password you entered.

After you log in to the application, you should be redirected to the posts index page. Your server output for that page should look something like this:

  Started GET "/" for 127.0.0.1 at 2014-03-18 18:59:02 -0500
  Processing by PostsController#index as HTML
➊   User Load (0.1ms) SELECT "users".* FROM "users"
      WHERE "users"."id" = ? LIMIT 1 [["id", 1]]
➋    (0.1ms) SELECT "users".id FROM "users" INNER JOIN
      "subscriptions" ON "users"."id" = "subscriptions"."leader_id"
      WHERE "subscriptions"."follower_id" = ? [["follower_id", 1]]
➌   Post Load (0.2ms) SELECT "posts".* FROM "posts"
      WHERE "posts"."user_id" IN (2, 1)
      ORDER BY created_at DESC
➍   User Load (0.1ms) SELECT "users".* FROM "users"
      WHERE "users"."id" = ? LIMIT 1 [["id", 2]]
    User Load (0.1ms) SELECT "users".* FROM "users"
      WHERE "users"."id" = ? LIMIT 1 [["id", 1]]
    CACHE (0.0ms) SELECT "users".* FROM "users"
      WHERE "users"."id" = ? LIMIT 1 [["id", 1]]
    Rendered collection (2.7ms)
    Rendered posts/index.html.erb within layouts/application (3.8ms)
  Completed 200 OK in 13ms (Views: 11.0ms | ActiveRecord: 0.6ms)

This page produces six queries. It first finds the user with id 1 ➊; this query looks up the current_user inside the authenticate_user! call in PostController. Next, the page finds the ids ➋ of the users the current user is following in the call to current_user.timeline_user_ids. It then finds posts ➌ where the user_id matches the id of the current_user or one of his or her followers.

Finally, the page queries for a user ➍ matching an id with SELECT "users".* FROM "users" three times in a row. That looks a little strange to me. My index page has three posts, but there are three extra queries. Let’s look at the index action in app/controllers/posts_controller.rb and see what’s happening:

  class PostsController < ApplicationController
➊   before_action :authenticate_user!

    def index
➋     user_ids = current_user.timeline_user_ids
➌     @posts = Post.where(user_id: user_ids)
                 .order("created_at DESC")
    end

  --snip--

This code calls authenticate_user! ➊ before each action. The index action finds the user_ids ➋ that current_user wants to see and then finds the posts ➌ matching those users. You’ve already accounted for those queries in the previous server output. Since the index action isn’t creating the three user queries, they must be coming from the view.

The index view renders the collection of posts. That means the source of these queries must be in the TextPost partial in app/views/text_posts/_text_post.html.erb:

  --snip-
    <div class="panel-body">
➊     <p><em>By <%= text_post.user.name %></em></p>
--snip--

Here’s the problem. The name ➊ of the user who created each post is displayed by calling text_post.user.name. If you check the ImagePost partial, you can verify it does the same thing. For every post displayed, an extra query is generated, which explains the three extra queries you saw in the SQL output.

Code that creates an extra database query for each record in a collection falls into a category of problems called N + 1 Queries. These problems are common in Rails applications, and they occur when associations on a collection are referenced without first loading the associated models.

In this case, I loaded a collection of posts into @posts. I then referenced the name for the user who created each post. Because I didn’t load all of those users in advance, Rails fetches them one at a time from the database as the page is rendered. These extra queries meant the three posts on the index page resulted in four queries. The number of queries is always one more than the number of items in the collection.

Luckily, this problem is easy to fix. In Rails, you can specify in advance all associations that are going to be needed with the includes method. This technique is called eager loading.

Let’s update the index action in PostsController to use eager loading now:

  --snip--
    def index
      user_ids = current_user.timeline_user_ids
➊     @posts = Post.includes(:user).where(user_id: user_ids)
                 .order("created_at DESC")
    end
  --snip--

Here, I chain the includes(:user) method ➊ to the query that sets @posts. The symbol passed to includes must match the name of an association on the model. In this case, post belongs_to :user.

With the includes method, Rails ensures that the specified associations are loaded using the minimum number of queries. After you save this file, refresh the index page in your browser and check the SQL output in your terminal:

  --snip--
    Post Load (0.3ms) SELECT "posts".* FROM "posts"
      WHERE "posts"."user_id" IN (2, 1) ORDER BY created_at DESC
➊   User Load (0.3ms) SELECT "users".* FROM "users"
      WHERE "users"."id" IN (2, 1)
  --snip--

The three queries to find each user have been replaced with ➊ a single query that finds all users at once.

Watch out for extra queries as you build applications. Look for calls like text_post.user.name in the view. Notice the two dots in that call. The two dots mean you’re accessing data in an associated model, which can introduce an N + 1 Queries problem, so you should preload the association before the view is rendered.