We’ve heard it again and again, like a nagging schoolmaster: Keep your Rails controllers skinny. Yeah, yeah, we understand. But that’s often easier said than done—because things get complex. And we need to talk to other parts of our codebase or to external APIs to get the job done.
Mailers. Stripe. External APIs. All that code starts to add up.
Ah Tss Push It…Push It Down the Stack
“Where should this code live?” you ask. The answer comes like a resounding chorus: “Push it down to the model layer!”
But what if we want to keep things simple? Models should actually reflect the business objects related to our app, according to domain-driven design and other approaches.
Time to get custom!
Crack open the ol’ app folder. What do you see? The usual fare? Guess what. Just because Rails comes with six folders doesn’t mean we’re restricted to six types of objects. Let’s make some new folders!
At Your Service
I like to create various kinds of service objects in my Rails apps. Tomek Pewiński’s 2014 article in Ruby Weekly does a great job of covering how to write service objects that help complete an action, like create_invoice or register_user.
While he puts all of his service objects into a single services folder, I like to get a little more granular. I’ll typically create an actions folder for things like create_invoice and folders for other service objects such as decorators, policies, and support. I also use a services folder, but I reserve it for service objects that talk to external entities, like Stripe, AWS, or geolocation services.
Here’s how the app folder might look with all of these subfolders in it:
app
|- actions
|- assets
|- controllers
|- decorators
|- models
|- policies
|- services
|- support
|- views
Earning Our Stripes
Let’s give it a try, right now! We’ll make a credit card service that uses the Stripe gem.
We’ll create an app/services
folder and touch a credit_card_service.rb
inside of it. It’s going to be a Plain Old Ruby Object™ (PORO).
It’s probably a good idea to wrap the calls to the Stripe gem in local methods like external_customer_service
and external_charge_service
in case we ever want to switch over to Braintree or something else. On object initialization, we’ll use dependency injection to accept charge amounts, card tokens, and emails. Our service will expose charge!
and create_customer!
methods to hook up our controllers.
# app/services/credit_card_service.rb
require 'stripe'
class CreditCardService
def initialize(params)
@card = params[:card]
@amount = params[:amount]
@email = params[:email]
end
def charge
begin
# This will return a Stripe::Charge object
external_charge_service.create(charge_attributes)
rescue
false
end
end
def create_customer
begin
# This will return a Stripe::Customer object
external_customer_service.create(customer_attributes)
rescue
false
end
end
private
attr_reader :card, :amount, :email
def external_charge_service
Stripe::Charge
end
def external_customer_service
Stripe::Customer
end
def charge_attributes
{
amount: amount,
card: card
}
end
def customer_attributes
{
email: email,
card: card
}
end
end
Hook it Up
Now we can write some clean, maintainable controller code. We keep the registration logic private—and if we ever want to change it, the controller doesn’t have to know anything about it.
# app/controllers/users_controller.rb
class UsersController < ActionController::Base
def create
@user = User.create(user_params)
registration = register_with_credit_card_service
if registration
# Save the id from the Stripe::Customer object
add_customer_id_to_user(registration['id'])
...
else
...
end
end
private
...
def register_with_credit_card_service
CreditCardService.new({
card: params[:stripe_token]
email: params[:user][:email]
}).create_customer
end
def add_customer_id_to_user(id)
@user.update_attributes(external_customer_id: id)
end
end
Test It Out
Since we’re just using a PORO, this should be nice and easy to test. Make a test/services
folder, and if you want to add its contents to your rake tasks, try this. Let’s assume that we already have a test_helper.rb
that includes the Rails helpers in ActiveSupport::TestCase and mocha.
# test/services/credit_card_service_test.rb
require 'test_helper'
class CreditCardServiceTest < ActiveSupport::TestCase
test 'it creates charges' do
params = {
amount: 500,
card: 'TOKEN'
}
Stripe::Charge.expects(:create).with(params).returns(true)
# This will return false if it fails
charge = CreditCardService.new(params).charge
assert charge
end
test 'it creates customers' do
params = {
email: 'test@example.card',
card: 'TOKEN'
}
Stripe::Customer.expects(:create).with(params).returns(true)
# This will return false if it fails
customer = CreditCardService.new(params).create_customer
assert customer
end
end
Keep It Clean
The last thing you want in your Rails app is a bunch of complicated controllers that are difficult to change. Though it may sound pedantic, those chants of “Skinny Controller, Fat Model” are right. It’s easy to answer “Where should I put this code?” with “Let’s open the app folder and see what cubbies I was given.”
Don’t be afraid to take your Rails project by the horns! You can create your own actions, decorators, support objects, and services. Start including these patterns in your Rails app and your code will come out clean and DRY—so fresh and so clean!
Deploy and run your Ruby apps on Engine Yard
{{cta(‘5019e5e3-8348-4b05-b8bf-ede6bb67025e’)}}