Rails on a Diet

A man with glasses and a beard, wearing a light gray suit and white shirt, smiles confidently against a plain white background.

Przemyslaw Swiercz

August 19, 2014 • 8 min read

Night view of a train yard with illuminated buildings and tracks, set against a city skyline with glowing skyscrapers.

More and more apps are being created with an API support. Growing popularity of Angular.js and Backbone.js makes it even more important part of new projects. Why is that? There is a trend to separate backend from frontend not only in terms of logic but also to split the project into two separate ones - pure API backend and client-side-only frontend. What's all the fuss about? It is simple - you have a nice and clear API for a javascript web application and therefore you do not need to worry about the assets pipeline and other full-stack projects related issues. And you get an API for mobile devices. For free.

Rails is a huge framework. It supports almost everything you need and more. You get nice templating engine with partials, cookies and flashes support, static assets and other goodies. However, when you are developing a pure API backend you do not need most of these.

Rails-api

There is a nice gem called rails-api which is sufficient for most of your needs. You can grab more details on this from this railscast. Here we want to dig into the internals of the default rails configuration and tune it for API purposes so we won't use rails-api gem.

Middlewares

Rails applications have few middlewares enabled by default. For Rails 4.1.4 these are:

1    Rack::Sendfile
2    ActionDispatch::Static
3    Rack::Lock
4    #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x007ff931376400>
5    Rack::Runtime
6    Rack::MethodOverride
7    ActionDispatch::RequestId
8    Rails::Rack::Logger
9    ActionDispatch::ShowExceptions
10    ActionDispatch::DebugExceptions
11    BetterErrors::Middleware
12    ActionDispatch::RemoteIp
13    ActionDispatch::Reloader
14    ActionDispatch::Callbacks
15    ActionDispatch::Cookies
16    ActionDispatch::Session::CookieStore
17    ActionDispatch::Flash
18    ActionDispatch::ParamsParser
19    Rack::Head
20    Rack::ConditionalGet
21    Rack::ETag
22    YouApp::Application.routes

tsx

You can check enabled middlewares on your own by running rake middleware. As you can see almost all of these are classes. Only LocalCache is an object so you will have a different address here.

We won't need all of these so let's get rid of the unnecessary ones. It is a good thing to keep middlewares configuration in a separate file so we create config/middlewares.rb and put the following code in here:

1    # load rb files from app/middlewares directory
2    # these are our custom middlewares
3    Dir[Rails.root.join('app/middlewares/*.rb')].each{|f| require f}
4
5    Rails.application.config.tap do |config|
6      # disable unnecessary default middlewares
7      config.middleware.delete ::Rack::Sendfile
8      config.middleware.delete ::ActionDispatch::Static
9      config.middleware.delete ::ActionDispatch::RequestId
10      config.middleware.delete ::ActionDispatch::Cookies
11      config.middleware.delete ::ActionDispatch::Session::CookieStore
12      config.middleware.delete ::ActionDispatch::Flash
13      config.middleware.delete ::ActionDispatch::Http::Headers
14      config.middleware.delete ::Rack::ETag
15
16      # remove headers: X-Frame-Options, X-XSS-Protection, X-Content-Type-Options
17      config.action_dispatch.default_headers = {}
18    end

tsx

You can drop a different set of middlewares if you want to. Next, we need to load this file from config/environment.rb

1# load middlewares config file
2require File.expand_path('..\/middleware', __FILE__)

tsx

Now, you can put your custom middlewares in app/middlwares directory. But remember to load them from config/middleware.rb e.g. if we want not to return X-Runtime header in every single response we need to manually hide it using a custom middleware. Deleting Rack::Runtime will fail in this case. In this situation you should insert your hiding middleware using:

1    # remove X-Runtime header
2    config.middleware.insert_before(::Rack::Runtime, ::HideRuntime)

tsx

The code for app/middlewares/hide_runtime.rb may look like this:

1    class HideRuntime
2      def initialize(app)
3        @app = app
4      end
5      def call(env)
6        status, headers, body = @app.call(env)
7        headers.delete('X-Runtime')
8        [status, headers, body]
9      end
10    end

tsx

Rails frameworks

OK, so we have dropped some unnecessary middlewares so far. The next thing to consider is to choose which of the default Rails frameworks we actually need. Let's take a look at config/application.rb.

1    require File.expand_path('../boot', __FILE__)
2
3    # Pick the frameworks you want:
4    require 'active_model/railtie'
5    require 'active_record/railtie'
6    require 'action_controller/railtie'
7    require 'action_mailer/railtie'
8    require 'action_view/railtie'
9    require 'sprockets/railtie'
10    require 'rails/test_unit/railtie'
11
12    # Require the gems listed in Gemfile, including any gems
13    # you've limited to :test, :development, or :production.
14    Bundler.require(*Rails.groups)
15
16    module MyApp
17      class Application < Rails::Application
18        # Settings in config/environments/* take precedence over those specified here.
19        # Application configuration should go into files in config/initializers
20        # -- all .rb files in that directory are automatically loaded.
21
22        # Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.
23        # Run 'rake -D time' for a list of tasks for finding time zone names. Default is UTC.
24        # config.time_zone = 'Central Time (US & Canada)'
25
26        # The default locale is :en and all translations from config/locales/*.rb,yml are auto loaded.
27        # config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s]
28        # config.i18n.default_locale = :de
29      end
30    end

tsx

You can freely comment out some of require statements. We will not need action_view orsprocets. If you prefer RSpec you can also drop test_unit. ActiveRecord is kinda fat so if you are going to use some NoSQL database you should check out MongoDB and its Mongoid framework. For SQL databases check out the DataMapper framework. Mongoid still depends on ActiveModel so we can leave it uncommented. If you are not planning to send emails from within your application then you should comment action_mailer and remember to drop config statements from files in config/environments directory. Finally we can end up with something like this:

1    # Pick the frameworks you want:
2    require 'active_model/railtie'
3    # require 'active_record/railtie'
4    require 'action_controller/railtie'
5    # require 'action_mailer/railtie'
6    # require 'action_view/railtie'
7    # require 'sprockets/railtie'
8    # require 'rails/test_unit/railtie'

tsx

Gemfile

In your Gemfile do not hesitate to use groups. Every gem which is essential only in development and/or test should be put in its group e.g. capistrano or pry-byebug should be wrapped in development group

1    group :development do
2      gem 'better_errors'
3      gem 'binding_of_caller'
4      gem 'pry-byebug'
5      gem 'capistrano'
6      # ...
7    end

tsx

This will prevent from loading extra code in your staging/production environments. Also feel free to use require: false for gems you do not want to be automatically loaded from your config/application.rb file.

1    gem 'koala', require: false

tsx

It means that if you want to use that gem you should first require it on top of your file - like in pure ruby code. It may be inconvenient but should speed up your application.

Api Controller

The most important part of your application. Since it's an API project we don't call it ApplicationController. It's just ApiController. First, don't declare this class as inherited from ActionController::Base. We don't want that. We don't need that. Use ActionController::Metal instead which is more lightweight and add only the modules you need.

OK, so now you have two strategies to follow. You can either include what you want or exclude what you don't want. I personally prefer the second approach. Notice that if you're using rabl or jbuilder templates you probably want to have rendering stuff included. Your ApiController should be something like this:

1    module Api
2      class ApiController < ActionController::Metal
3        WITHOUT = [
4          AbstractController::Translation,
5          AbstractController::AssetPaths,
6          ActionController::UrlFor,
7          ActionController::Redirecting,
8          ActionController::Renderers::All,
9          ActionController::ConditionalGet,
10          ActionController::Caching,
11          ActionController::MimeResponds,
12          ActionController::Cookies,
13          ActionController::Flash,
14          ActionController::RequestForgeryProtection,
15          ActionController::ForceSSL,
16          ActionController::Streaming,
17          ActionController::DataStreaming,
18          ActionController::HttpAuthentication::Basic::ControllerMethods,
19          ActionController::HttpAuthentication::Digest::ControllerMethods,
20          ActionController::HttpAuthentication::Token::ControllerMethods,
21          ActionController::Instrumentation,
22          ActionController::ParamsWrapper
23        ]
24
25        ActionController::Base.without_modules(*WITHOUT).each do |el|
26          include el
27        end
28
29        prepend_view_path 'app/views'
30      end
31    end

tsx

If ou want your views to load correctly remember to set the view path as above. Keep in mind that if you don't like excluding approach you can always take a look into ActionController::Base class and include only those modules you really need. Here's the array of all the modules included in ActionController::Base by default:

1    MODULES = [
2      AbstractController::Rendering,
3      AbstractController::Translation,
4      AbstractController::AssetPaths,
5
6      Helpers,
7      HideActions,
8      UrlFor,
9      Redirecting,
10      ActionView::Layouts,
11      Rendering,
12      Renderers::All,
13      ConditionalGet,
14      RackDelegation,
15      Caching,
16      MimeResponds,
17      ImplicitRender,
18      StrongParameters,
19
20      Cookies,
21      Flash,
22      RequestForgeryProtection,
23      ForceSSL,
24      Streaming,
25      DataStreaming,
26      HttpAuthentication::Basic::ControllerMethods,
27      HttpAuthentication::Digest::ControllerMethods,
28      HttpAuthentication::Token::ControllerMethods,
29
30      # Before callbacks should also be executed the earliest as possible, so
31      # also include them at the bottom.
32      AbstractController::Callbacks,
33
34      # Append rescue at the bottom to wrap as much as possible.
35      Rescue,
36
37      # Add instrumentations hooks at the bottom, to ensure they instrument
38      # all the methods properly.
39      Instrumentation,
40
41      # Params wrapper should come before instrumentation so they are
42      # properly showed in logs
43      ParamsWrapper
44    ]

tsx

Dependencies

When using the described setup you should be aware of the fact that you can get errors if some of your gems are using something you dropped from your application. As an example you may take Draper (decorators framework) which won't work until you have ActionDispatch::RequestId middleware loaded.

Next?

From now on it's all up to you. If you've chosen only those middlewares and frameworks you need your application should be lighter, cleaner and even faster comparing to full Rails setup.

That's all for now. Till next time.

Web Development

Let’s Create a Great Website Together

We'll shape your web platform the way you win it!