Building a Rails API
March 20, 2020
Need an API? Ruby on Rails presents a strong argument for an API framework. True, there are some Performance Considerations to take into account and we probably won’t be seeing those sub-millisecond performances that we might see if we were using something like Elixr - enter Haskell, but there are still plenty of valid reasons for choosing Ruby on Rails for an API.
- Active Record, despite its flaws, is still quite useful for a quick CRUD-based application where the Model is relatively flat (eg. not a lot of class hierarchies). There are alternatives to AR that we won’t discuss here and for this tutorial we will be working with AR.
- Ruby on Rails is written in Ruby, a dynamic, general-purpose programming language. Also RoR is a mature framework which means refined and stable code.
- Building applications in RoR is fast and easy, which is an excellent choice if you’re on a tight budget and/or under tight deadlines.
Ruby 3.0 is scheduled to release this December with claims of a 3x3 performance boost from Matz
Shall we explore this Rails API thing?
This tutorial will cover building the application on OS X using Rails 6 and Ruby 2.7.0
Apple bundles Ruby with OS X, however, for development purposes we should use RVM for managing our own builds and versions. Here is an article from Jeffrey Morgan explaining some of the setup with this configuration.
Deploy Early and Often
Heroku is a great choice for RoR development and offers a service at no-cost to get started. For this tutorial, let assume we’ve named our application in Heroku:
According to the official Rails documentation, if we want to create an “API-only” version of Rails, we can do so by passing the
--api parameter when we run the
rails new command. Make sure you’ve installed rails with
gem install rails. We’re also going to pass
--database along with the command and create the MySQL database.
rails new awesome-rails-api --api --database=mysql
Next we will run
bundle install and
rake db:create in the
awesome-rails-api directory. But first, let’s setup our development and production values in the
config/database.rb file for such things as our database names.
Because we selected the JawsDB MySQL resource, we notice that the value has been set for the
JAWSDB_URL key in the config vars section under the settings for the Heroku app. In
config/database.rb, our production settings contain this key wrapped in a syntax to be read as an environment variable.
production: <<: *default url: <%= ENV['JAWSDB_URL'] %>
Next, Heroku wants a
Procfile to load the Puma webserver configuration at
We make the Profile and load the one-liner into the file:
echo "web: bundle exec puma -C config/puma.rb" >> Procfile
We configure the
config/puma.rb according to the Heroku Documentation and get ready to test the server locally.
We run the server locally with:
Our server seems to run and we visit the application at:
We see our first error in big scary red and white type!
Have no worry! Rake can take care of this with ease!
We see the output
Created database 'awesome_rails_api_development' Created database 'awesome_rails_api_test'
Cool, and we see our app!
Written by Mike Hacker, a Native Texan, who lives and works in the Austin/San Antonio, Texas area. You should follow him on Twitter