Rails on a Diet
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 seperate backend from frontend not only in terms of logic but also to split the project into two seperate ones - pure API backend and client-side-only frontend. What’s all the fuss about?

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:
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:
tsx
You can drop a different set of middlewares if you want to. Next, we need to load this file from config/environment.rb
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:
tsx
The code for app/middlewares/hide_runtime.rb may look like this:
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.
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:
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
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.
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:
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:
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.
Let’s Create a Great Website Together
We'll shape your web platform the way you win it!
More posts in this category
February 05, 2025 • 10 min read
READ MORELearn more about api first cmsAPI-first CMS: What Options You Have (Web Dev Agency's Take)
According to the 2024 State of the API Report by Postman, 74% of organizations are adopting API-first strategies. This statistic isn’t just impressive—it signals a major shift in how businesses operate. While API-first approaches have long been a staple in software development, they're now reshaping content management as well. More and more companies are realizing that traditional CMS platforms can't keep up with the demand for flexibility, speed, and seamless integrations.
January 23, 2025 • 15 min read
READ MORELearn more about best cms for saas top cloud based solutionsBest CMS for SaaS: Top Cloud-Based Solutions
Choosing the right Content Management System (CMS) is a critical decision for your SaaS business. Your unique needs require solutions that are not only flexible, scalable, and user-friendly but also tailored to meet the demands of a fast-paced, customer-focused industry. A CMS should simplify your workflows and help you deliver personalized, high-quality digital experiences.
December 12, 2024 • 10 min read
READ MORELearn more about headless cms for vueWe Picked the Best (Headless) CMS for Vue
Picture a digital experience where content effortlessly flows across platforms, development is agile, and performance is unmatched. By combining the power of Vue.js, a progressive JavaScript framework, with a modern headless CMS, you can achieve all this and more.