Beautiful Abstractions

Param Validation

When it comes to parameter validation for incoming requests, I like how JS libraries like Zod and Joi allow you to define schemas for your parameters in a way that is granular yet easy to work with. I find this more useful than the Rails default which would involve writing something like params.require(:post).permit(:title, :body).

Tapping onto dry-rb again, we can easily emulate a similar interface in Ruby.

# app/controllers/concerns/parameter_validation.rb
#
module ParameterValidation
  extend ActiveSupport::Concern

  included do
    class_attribute :parameter_schemas, instance_writer: false, default: {}

    before_action :validate_parameters, prepend: true
  end

  class_methods do
    def params_for(action, schema = nil, &block)
      schema ||= Dry::Schema.Params(&block)

      parameter_schemas["#{controller_path}##{action}"] = schema
    end
  end

  def params
    if validated_parameters
      ActionController::Parameters.new(validated_parameters).permit!
    else
      super
    end
  end

  private

  attr_reader :validated_parameters

  def validate_parameters
    schema = parameter_schemas["#{controller_path}##{action_name}"]

    return if schema.blank?

    validation = schema.(request.params)

    if validation.success?
      @validated_parameters = validation.to_h.merge(
        {
          "authenticity_token" => request.params[:authenticity_token],
          "page" => request.params.dig(:pagination, :page),
          "page_size" => request.params.dig(:pagination, :page_size),
        }
      )
    else
      render json: { errors: validation.errors.to_h }, status: 403
    end
  end
end

The above concern allows you to define schemas for your parameters in a way that is both expressive and easy to understand.

# app/controllers/application_controller.rb
# 
class ApplicationController < ActionController::Base
  include ParamValidation
end

# app/controllers/posts_controller.rb
# 
class PostsController < ApplicationController
  params_for :create do
    required(:post).schema do
      required(:title).filled(:string)
      required(:body).filled(:string)
    end
  end

  def create
    post = Post.new(
      title: params[:post][:title],
      body: params[:post][:body],
      user_id: current_user.id
    )

    if post.save
      render json: post, status: :created
    else
      render json: post.errors, status: :unprocessable_entity
    end
  end
end

(Admittedly, this doesn't have the code completion ergonomics that something like Vine provides through Typescript's type system.)

Soft Deletes

Soft deletes are a common pattern in software applications, especially since the app stores require "account deletion (*wink* *wink*)" to be an option for users... An annoying requirement, but nothing that a simple "deleted_at" column and a few lines of Ruby can't solve. For legal reasons, that's a joke.

# app/models/concerns/soft_deletable.rb
#
module SoftDeletable
  extend ActiveSupport::Concern

  included do
    scope :active, -> { where(deleted_at: nil) }
    scope :deleted, -> { where.not(deleted_at: nil) }
    scope :with_deleted, -> { unscope(where: :deleted_at) }

    default_scope -> { active }
  end

  def deleted?
    deleted_at.present?
  end

  def active?
    !deleted?
  end

  def soft_delete
    update_column(:deleted_at, Time.current)
  end

  def restore
    update_column(:deleted_at, nil)
  end

  def destroy
    raise ActiveRecord::RecordNotDestroyed, "Cannot destroy soft deletable record"
  end
end

class User < ApplicationRecord
  include SoftDeletable
end

So simple. So elegant.

Response Pipeline

Now for a more involved example! Imagine a Rails concern that standardizes API response handling across a Rails application by providing a unified serialization and pagination interface.

# app/controllers/posts_controller.rb
#
class PostsController < ApplicationController
  # NOTE: The following ResponsePipeline module is intended to be included in 
  # ApplicationController to standardise the response format across the app
  include ResponsePipeline

  def index
    posts = Post.all
    
    render json: serialize(posts)
  end
  
  def show
    post = Post.find(params[:id])
    
    render json: serialize(post)
  end
  
  def filtered_index
    posts = Post.where(published: true)
    
    # Custom serializer option
    render json: serialize(posts, serializer: PublishedPostSerializer)
  end
  
  def with_comments
    post = Post.find(params[:id])
    
    # Pass additional options to serializer
    render json: serialize(post, include_comments: true)
  end
end

# app/controllers/concerns/response_pipeline.rb
#
module ResponsePipeline
  extend ActiveSupport::Concern

  included do
    before_action :set_pagination_params
  end

  private

  def set_pagination_params
    @page = (params[:page] || 1).to_i
    @per_page = (params[:per_page] || 25).to_i
    @per_page = 100 if @per_page > 100 # Limit maximum per_page
  end

  def serialize(records, options = {})
    if records.respond_to?(:to_a)
      paginated_records = paginate(records)
      serialized_data = paginated_records.map { |record| serialize_record(record, options) }
      
      {
        data: serialized_data,
        meta: {
          current_page: @page,
          per_page: @per_page,
          total_pages: (records.count.to_f / @per_page).ceil,
          total_count: records.count
        }
      }
    else
      serialize_record(records, options)
    end
  end

  def paginate(records)
    records.limit(@per_page).offset((@page - 1) * @per_page)
  end

  def serialize_record(record, options = {})
    serializer_class = options[:serializer] || "#{record.class.name}Serializer".constantize
    serializer_class.new(record, options.except(:serializer)).as_json
  rescue NameError => e
    # Fallback to simple as_json if serializer not found
    record.as_json(options)
  end
end

It automatically handles both single-record and collection responses, applies consistent pagination, manages serializer selection, and structures the response format to include both the serialized data and metadata for collections.

This centralization helps maintain consistency across endpoints, a powerful and useful abstraction indeed.

The above examples barely scratch the surface of what is possible with Ruby! Ruby pushes metaprogramming and object oriented design in a way that allows you to craft tailored abstractions for your business logic and domain. We often associate Ruby with it being an expressive programming language, but what does expressiveness actually mean? Personally, it is the essence of being able to capture a wide surface area of business logic and context with very little code and boilerplate. It is about conveying a lot, with very little. It is about compressing complexity.