May 22, 2020
Ruby may be over 25 years old, but it remains popular in the software community for its focus on programmer happiness. Building software with Ruby often involves leveraging one or more popular frameworks for the purpose of increasing productivity by relying on existing solutions to common problems. Ruby frameworks generally fall into two categories: web-facing frameworks and background job frameworks.
Deciding which Ruby framework to use on your project is an important decision with long-lasting effects. It’s important to consider the needs of the application as well as any future plans or ambitions, as one option may be better suited than another over the long term.
One aspect of Ruby frameworks to consider is whether a traditional framework or micro framework is more appropriate for your project.
Micro frameworks will allow you to mix and match different parts of your application, potentially providing a more optimal solution for your needs than a single framework that handles most concerns. However, the overhead of integrating multiple smaller frameworks together can add additional costs to the development process over the life of your application, such as having to teach developers new to the project how the components fit together.
Popular Ruby frameworks generally fall into two categories: web frameworks and background job frameworks.
Web frameworks handle responding to incoming web requests, such as loading an HTML page or making a JSON request to an API.
Background job frameworks execute code outside of the traditional request-response cycle in which web frameworks operate. Background jobs are often used for procedures that cannot be completed within the time needed to respond to a web request, or for procedures that need to run on a recurring basis, such as with `cron`.
Ruby on Rails (or just “Rails”, for short) is by far the most ubiquitous web framework written in Ruby. Created in 2005, Rails powers some of the biggest web applications, including Basecamp, GitHub, Shopify, Airbnb, Square, and ScoutAPM.
Ruby on Rails is famous for its “convention over configuration” approach, which enables a high level of developer productivity. Like Ruby, it is famous for its ruthless focus on developer happiness.
Rails was early to embrace the Model, View, Controller pattern in the Ruby community. It also encourages adherence to RESTful routes, a now-common pattern for laying out web applications.
Rails provides built-in solutions for many common web application needs, including:
Being the most popular Ruby Framework, Rails has a significant mindshare in the development community. When considering which Ruby web framework to use, it’s a safe choice.
Formerly named Lotus, Hanami is a full-stack Ruby web framework. Hanami is built with a strong emphasis on speed and simplicity.
Like Ruby on Rails, Hanami provides several modules for common web application functionality:
Unlike Rails, Hanami encourages building applications composed of multiple sub-components, each with its own directory in `apps` with views, controllers, and configuration.
Hanami’s modules are able to be used independent of the framework.
Sinatra is a microframework, in stark contrast with Rails and Hanami.
Sinatra provides a simple Domain Specific Language (DSL) that matches a web request route to a block of Ruby code. Sinatra is a great framework choice if your application doesn’t need the complexity of larger frameworks.
Like Rails and Hanami, Sinatra leverages the Rack (https://github.com/rack/rack) web server interface.
Sinatra is a good starting point for many applications. It’s a good option for applications that may eventually move to using a fuller-featured framework like Rails.
Grape is a Ruby web framework focused on creating REST APIs. It can run directly on Rack or alongside other frameworks such as Rails or Sinatra.
Grape supports several API versioning strategies out of the box: Path, Header, Accept-Version, and Param.
It’s possible to use Rails’ ActiveRecord with Grape, enabling Rails models to be used in Grape-powered APIs.
Grape provides a DSL for validating & coercing parameters, such as defining an Integer attribute for a `post_id` parameter. The framework also allows for optional parameters to be declared with a default value. It’s possible to define custom types and corresponding coercions as well.
Grape’s parameter support also includes validation of nested parameters and dependent parameters, and to group parameter coercions to reuse common behavior.
GitLab is a prominent user of Grape.
An extraction from Shopify, Delayed::Job is built on top of a traditional relational database, leveraging a `delayed_jobs` table. This architecture avoids the cost and overhead of running an additional data store such as Redis, making it especially well-suited for hobby applications.
Delayed::Job allows jobs to be prioritized within a single queue, using a `priority` parameter. By setting a `run_at` parameter, jobs can be queued to run in the future.
Unlike other background job frameworks, Delayed::Job enables a single method on an object to be processed in the background. For example:
```ruby # without delayed_job @user.activate!(@device) # with delayed_job @user.delay.activate!(@device) ```
(Example from `https://github.com/collectiveidea/delayed_job#queuing-jobs`)
Created by GitHub co-founder and CEO Chris Wanstrath, Resque is a Ruby background job framework backed by the Redis in-memory data store. It takes a lot of inspiration from DelayedJob.
Resque ships with Resque::Web, a simple web interface that allows for job queues to be monitored and inspected from a browser.
Resque is a proven option and a reliable choice for a background job framework.
Sidekiq is a background job framework for Ruby, backed by Redis. By some benchmarks, it has ~30x the throughput of DelayedJob and Resque.
Sidekiq includes a Web UI for monitoring an application’s background workers.
While Sidekiq supports Rails, it’s not a requirement.
In addition to full-featured open-source option, Sidekiq has Pro and Enterprise products to support the needs of larger companies, making it an especially good choice for corporate use.
Sneakers is a Ruby background job framework powered by RabbitMQ. Sneakers is designed to minimize its overhead, an important concern in high-volume disciplines such as event processing.
Being backed by RabbitMQ gives the library several advantages over Redis-backed frameworks, such as persistent queues.
If you’re working with a high volume of fast background jobs, Sneakers could be a good fit for your application.
Scout’s Ruby monitoring includes built-in support for web frameworks Ruby on Rails, Sinatra, and Grape along with background job frameworks Delayed::Job, Resque, and Sneakers. It also instruments several datastore tools automatically, including Redis and ActiveRecord, which are used by many Ruby frameworks.
After over 25 years in existence, Ruby remains a great option for building web applications. With many well-established web and background-job frameworks, it’s a reliable choice when it comes to both developer happiness and productivity.