As Ruby has become more and more popular over the years, many web development frameworks have emerged. Some of them are highly focused on building whole websites (like Ruby on Rails), while others are more simple and to the point, like Sinatra. Both ends of the spectrum have advantages and disadvantages when it comes to creating what you need.
Related: How to convert Rails App into an API
In this article, we’d like to list Ruby frameworks that are useful for developing REST APIs. We will give some examples of what it takes to create an endpoint and compare each framework to the previous. This will hopefully give you a quick idea of which one is better suited for your needs.
1. Roda
Roda describes itself as a “Routing Tree Web Toolkit”. It’s a very small framework where you describe your routes as a tree, where each branch matches a part of the route. Take a look at the example on their website:
require "roda" class App < Roda route do |r| # GET / request r.root do r.redirect "/hello" end # /hello branch r.on "hello" do # Set variable for all routes in /hello branch @greeting = 'Hello' # GET /hello/world request r.get "world" do "#{@greeting} world!" end # /hello request r.is do # GET /hello request r.get do "#{@greeting}!" end # POST /hello request r.post do puts "Someone said #{@greeting}!" r.redirect end end end end end run App.freeze.app
Notice how the routing tree starts with the route
method. From here, a root
block is defined, which matches against the /
path. In this particular case, we redirect to the /hello
path immediately. Next, a hello
branch is defined. Since each branch is just a plain ruby block, we can define variables, call a database, among other things. Then the world
branch is defined as a GET method, along with the call to is
. This last one matches the current branch (that is, the /hello
path), where we can match GET and POST requests.
Roda is no doubt an extremely simple web framework. It can be extended using plugins, most of which are already included. This enables you to build your application starting from simple to more complex.
2. Sinatra
Sinatra is a slight step up in terms of complexity from Roda. It’s slower and more memory-intensive than Roda, but a tad simpler to work with. See this example:
require 'sinatra' get '/' do redirect '/hello' end before '/hello*' do @greeting = 'Hello' end get '/hello/world' do "#{@greeting} world!" end get '/hello' do "#{@greeting}!" end post '/hello' do puts "Someone said #{@greeting}!" redirect '/' end
The example above behaves almost identically to the Roda example. In general, they’re both very similar in complexity and size. So what makes these two so different? For one, performance. Like mentioned before, Roda is much faster than Sinatra and uses a lot less memory. Now, this is not a big deal if you’re developing an extremely small and simple API, but, the more complex it gets, the more you start to see this performance hits.
Why would you want to use Sinatra over Roda? Roda is more of a router than a full blow framework. This makes it very fast, but it also means you have to either start adding plugins on top of it to get some slightly more complex things done. Sinatra has more “batteries included” and behaves more similarly to, say, Rails, for example. It’s a bit easier to get some things done.
3. Padrino
It’s very possible you haven’t heard of Padrino. This framework is actually built on top of Sinatra. The objective of Padrino is to bring the simplicity of Sinatra and the convenience of Rails together, so to speak. If you look at their documentation you’ll notice the framework offers project generators, scaffolding, and even an admin generator. The framework also leverages the convention-over-configuration approach, where most of the grunt work is already done for you when you generate a project. You’re able to easily structure your app into controllers, models, and views, without having to think where to put what.
Since it’s built on top of Sinatra, the previous example would still mostly apply. Padrino offers some small abstractions for you to define controllers, like for example:
YourApp::App.controllers :hello do before do @greeting = 'Hello' end get :index do "#{@greeting}!" end get :world, map: '/hello/world' do "#{@greeting} world!" end post :index do puts "Someone said #{@greeting}!" redirect '/' end end
Since Padrino introduces the concept of controllers to the framework, things look somewhat different than in Sinatra. Controllers have methods, like in rails, which map to endpoints in your API.
Considering all of the tools and features Padrino offers right out of the box, you can look at it as being in the middle point between Sinatra and Ruby on Rails. It’s a great mixture of simplicity, performance and ease of development.
4. Ruby on Rails
You’ve definitely heard of Rails. It’s been the go-to web development framework in Ruby for years. It has evolved to be a very complex and complete framework. Since it provides everything from templating, emails, to even a WYSIWYG editor via Action Text, it’s a very heavy library. Most don’t consider this framework for APIs since it’s “too bloated”. And they’d be right, for the most part.
[insert editor screenshot here?]Fortunately, Rails added an API mode a while back, where one can generate a Rails application with a smaller stack specific for API-only apps. You can also leverage the options in the rails generator to skip loading modules you don’t need. If you don’t need Action Mailer or Action Storage (for email sending and file storage, respectively), you can avoid them:
rails new my-app --api --skip-action-mailer --skip-active-storage
Of course, using Rails for a simple API like the examples above is completely overkill. Rails is better suited for very large, complex applications, and choosing it for one or two endpoints will add too much unnecessary overhead that will make your API slower than needed.
Which Ruby Framework Should You Choose?
There are a lot of factors to consider when choosing the tools for a project. Performance, ease-of-use, and community are some most important. You also need to consider the size of the project. Of course, this is not always obvious at the beginning, but you can get a rough idea to help point you in the right direction.
Performance
If you’re looking for performance, look no further than Roda. It’s by far the fastest of the four. Now, of course, there are even faster options out there, it’s all a matter of the tradeoff between convenience of development and speed. If you look at the chart below, you’ll see how much faster Roda is compared to the other three.
These benchmarks were run on my own laptop, so feel free to run them yourself to verify! Funnily enough, Padrino ranks a little higher than Sinatra. Padrino has received a bunch of performance upgrades over its lifetime, but keep in mind that the benchmark examples are very minimal, and Padrino apps tend to get more complex and bigger than Sinatra apps.
Ease of Use
This one is a bit subjective. If you’ve always worked with Rails, then choosing Rails would be a very safe choice. Even though its performance is not that good compared to the others, your experience with it make development a lot easier. Now, trying to see this more objectively, Sinatra can be seen as one of the simplest. Its learning curve is not that steep, and you can achieve quite a lot with very little code, while Rails will take you a while to get started and the number of features it provides might be overwhelming depending on the project.
Community
A framework’s community is a good indicator of how easy it will be to work with it. The same goes for the language. For Rails, the community is huge, and it’s a great point in favor. Finding gems and documentation is extremely easy. Roda and Padrino are not extremely well known, and that is something to consider when choosing them. Fortunately, Padrino shares a lot with Sinatra, and most gems built for Rails will also work with Padrino with minor or no adjustments.
Your Needs
In the end, it all comes down to the project you’ll build and what you’ll need. Building a very small project? Give Roda or Sinatra a shot. You won’t spend too much time digging into internals or reading documentation since the project is too small to get you there. If you’re going for something medium, Padrino is a great choice. It’s relatively fast and gives you a lot of the convenient tools Rails does without the performance penalty. If you’re going for a big project, where you know you’ll need to integrate email, WebSockets, or something similar, then Rails is a great choice.
Summary: Best Ruby Frameworks
Here’s a quick comparison table of all four frameworks, which should give you an overview of each and help you choose easier:
Performance | Ease of Use | Community | Good for | |
Roda | Very fast, small memory footprint | Simple, requires plugins for more functionality | Small, might be tricky to find documentation for some things | Small or highly performant projects |
Sinatra | Fast, small memory footprint | Simple | Medium | Small projects |
Padrino | Fast (just as fast or even faster than Sinatra), medium memory footprint | Combines the simplicity of Sinatra with the convenience of Rails | Medium | Medium to large projects |
Ruby on Rails | Medium | The complex and somewhat steep learning curve | Huge. Gems and documentation are widely available | Large projects |
Conclusion
We hope this article gave you an idea of the options you have when building an API. Like we mentioned before, it really boils down to your particular needs and knowledge. You should also keep in mind that there are a lot more ruby frameworks out there, so do some digging!
Leave a Reply