Which Ruby Framework is Best? Use This Decision Tree

Search "best Ruby frameworks" and Google will give you a dozen posts that all say the same thing: a table ranking Rails, Sinatra, Hanami, Grape, and Roda, followed by a paragraph on each. None of them tell you which one to use for your project.

That's because a ranking doesn't fit this problem. These frameworks aren't better or worse versions of each other. They're built for different jobs. Rails optimizes for full-stack productivity. Hanami optimizes for architectural boundaries. Sinatra and Roda optimize for simplicity and speed. Grape optimizes for API design. Asking which one is "best" is like asking whether a hammer is better than a wrench.

So instead of another ranked list, this post gives you a decision tree. Answer two questions, and you'll get a framework recommendation along with the trade-offs you're accepting by choosing it.

Find your framework

Six possible answers can come out of that tree: Rails, Hanami, Rails in API mode, Grape, Roda, and Sinatra. I’ve written out below the reasoning behind each one, so you can sanity-check your result or dig into the option you didn't pick.

Rails: for full-stack apps you're shipping fast

Rails is the right call when you're building a standard web app: forms, sessions, a database, and a team that wants to move quickly. Speed is the ethos Rails was built around. It favors convention over configuration, so your team spends time on the app instead of deciding how to structure it.

Rails has also gotten lighter to operate since its early reputation for needing a heavy stack of add-on services. With the latest Rails 8, the Solid Stack (Solid Cache, Solid Queue, and Solid Cable) handles caching, background jobs, and WebSockets using SQLite or PostgreSQL instead of requiring Redis. Kamal 2 ships zero-downtime deploys to any VPS, which reduces how dependent you are on a platform like Heroku.

The trade-off: Rails has opinions, and it works best when your project doesn't fight them. An unusual data model or a workflow that doesn't map to CRUD will cost you more effort in Rails than it would in a framework with fewer built-in assumptions.

Hanami: for complex domains and multiple teams

Hanami is best when your application is domain-heavy and more than one team will work on it over several years. Its explicit layers (actions, entities, repositories) create boundaries that the framework enforces, not boundaries your team has to remember to respect.

That matters a lot as your codebase grows. In Rails, a shortcut in one corner of the app can quietly leak into another, because the framework's conventions are implicit and easy to bend. Hanami makes those seams explicit, so a violation is harder to introduce by accident.

The trade-off: Hanami's ecosystem is smaller than Rails'. You'll find fewer tutorials, fewer gems built specifically for it, and a steeper learning curve for developers who've only worked in Rails' more implicit style.

Rails in API mode: for straightforward REST APIs

If you're building an API and it's a standard REST service, Rails in API mode is the best choice. You get ActiveRecord, background jobs, and the rest of the Rails gem ecosystem, minus the view layer you don't need.

By not choosing full Rails, you’ll skip the asset pipeline and view rendering, but you keep everything else that makes Rails productive for data-backed applications.

The trade-off: You'll still carry some of Rails' weight, like boot time and its dependency surface, for a job that a leaner framework could technically handle with less.

Grape: for APIs that need fine-grained control

Grape is built specifically for REST-like APIs, and it shows: versioning, parameter validation, and response formatting are first-class concerns instead of things you bolt on.

Choose Grape when your API's requirements go beyond "return some JSON". With Graph you can have multiple API versions running side by side, precise control over serialization, and a validation layer that doesn't come from adapting a full-stack framework to a job it wasn't originally built for.

The trade-off: You lose Rails' batteries. Background jobs, ORM conveniences, and generators aren't included, so you'll rebuild what you need piece by piece or add gems to fill the gaps.

Roda: for lean, high-performance services

Roda is a thin, plugin-based routing framework built directly on Rack. If you're running a webhook relay or another single-purpose service where memory footprint and requests-per-second per dollar matter, Roda gives you almost nothing you didn't ask for.

Roda doesn't apologize for what it leaves out. A Roda app starts with a router and adds capability only through plugins you explicitly include, so the framework's footprint stays close to what your service actually uses.

The trade-off: Because functionality comes from plugins, you'll spend more time reading Roda's documentation to find the right one instead of assuming a feature exists the way you might in Rails.

Sinatra: for the smallest possible app

Sinatra is the simplest way to get a Ruby app answering HTTP requests. No folder conventions, no configuration ceremony, and often no more than a single file.

That makes it a good fit for small scripts, prototypes, and services that genuinely stay small. If you want to write a handful of routes and move on, Sinatra gets out of the way faster than any other option here.

The trade-off: Sinatra won't stop you from writing an unmaintainable 800-line file once a "small service" quietly grows past its original scope. It has no opinion about that, for better or worse.

When the tree doesn't give you a clean answer

Decision trees simplify. Real projects don't always cooperate, so here are a few cases where the answer above deserves a second look.

High traffic, small team. The tree points toward Roda for performance and Rails for a small team's productivity, and a genuinely high-traffic app with only one or two engineers pulls in both directions. In practice, start with Rails unless you already know your bottleneck is the framework itself. Most performance problems at this stage come from database queries and caching strategy, not the web framework, and Rails gives a small team more leverage to fix those.

A REST API today that might need GraphQL-like flexibility later. If you're not sure whether you'll need Grape's fine-grained control down the road, start with Rails in API mode. Moving from a simple REST setup to Grape later is a more contained migration than trying to simplify an over-engineered API from day one.

A "small service" you suspect won't stay small. If a Sinatra or Roda project has already started growing past a single file, that's a signal, not a failure. Reevaluating with Rails or Hanami once real structure is needed costs less than continuing to patch a script that has outgrown its shape.

What the decision tree doesn't cover

None of these six frameworks stops you from shipping bugs. What matters is how fast you find out.

That's what Rollbar is for. It's a code-first error monitoring platform with a Ruby SDK that drops into any of the six setups above in a few minutes. It groups similar errors automatically, shows you the stack trace and deploy that introduced a bug, and pairs errors with session replay so you can see what the user was doing when things broke.

If you'd rather skip straight to the fix, Rollbar's new Resolve agent will review your codebase, figure out what's causing a given error, and open a tested pull request with the fix. You just approve it.

Rollbar has a generous free tier (5,000 error occurrences and 1,000 session replays a month, no credit card required) plus a 14-day full-access trial on paid plans.

Start monitoring your Ruby app with Rollbar →