Ruby Web Development Microframework: Cuba

Article originally published in the Neo blog.

We have many tools from which to choose when we’re facing a new web project. With applications tending to use a modular architecture on the web, and developing towards APIs, we’re building code that’s better to reuse and easier to test.

Rails is the most popular framework in Ruby when building web applications. Also, it’s an entrance technology for most new Rubyists due to its popularity. It’s a full-stack framework, opinionated and a great tool for specific uses. It tells you from the start it’s opinionated, it was built for convention over configuration, so it has a way to do things which it considers is the best way. But most programmers are opinionated themselves, so there’s the scenario where we need more control, mostly when we need to build lightweight applications.

This is the scenario where small Ruby web toolkits shine. The most popular of them being Sinatra, which has a very widespread use and is a great solution for web apps. It’s generally the preferred tool when splitting a Rails app into several smaller apps. It was inspired by Camping, part of the legacy left to the Ruby Community by _why. Camping defined itself as a microframework, so that’s how these toolkits are generally named versus the enormity of Rails and it’s way of doing things. They are good solutions when we won’t use everything Rails has to offer. That being said, Rails 4 is headed towards modularizing the framework and some features are being extracted into gems. There’s also a lot of customization available, even if most developers tend to accept its conventions.

Microframeworks are basically a thin abstraction layer over the HTTP protocol to route requests and respond with the desired content. They allow us to customize every aspect of the project. We can choose and add our solution for testing, orm, templates, etc. This way, every new project which we build on top of a microframework becomes our own customized web development framework, tailored to our project’s needs.

On RubyConf Argentina, Cuba’s author Michel Martens gave a talk about minimalist tools. He exposed a good point about dependencies in big tools such as Rails or Devise, which have a big list of dependencies, which at the same time have dependencies themselves. Sometimes these tools create problems for the developers, including functionality we don’t need or expect, for which we need to create workarounds. So we are sometimes bloating our projects before even starting to write our first lines of code. Minimalist kind of tools, tools that solve the one problem you are trying to solve and none more, are the lean way to go. All the extra functionality in big libraries or frameworks is unnecessary, therefore waste.

Cuba integrates templates via Tilt. The code is pretty simple, you can get a simple index page with something like this:

cat index.rb
 
Cuba.use Rack::Session::Cookie
 
Cuba.define do
    on get do
        on "hello" do
            res.write "Hello world!"
        end
 
        on root do
            res.redirect "/hello"
        end
    end
end

And to be able to run this, create a config.ru file:

# cat config.ru
require "./index"
 
run Cuba

Now just rackup or shotgun it, and you have your web application running. You can read more about it on github, I encourage you to check it out and build a web app yourself.

Microframeworks such as Cuba are being used for real projects right now, we’ve been working on a project we started building with Cuba some months ago. We started adding the needed libraries with each iteration. Keeping the minimalist mindset, we went for minitest for testing, and used Capybara when we started writing the front-end.

We used Thor for tasks such as creating migrations and running tests, Sequel as the ORM and ERB for templates. We had a general idea of what the project needed, so we started iterating small. This also helps us prevent featuritis, adding libraries or features which might be useful eventually, but there’s no certainty we’ll actually use them.

The project has come a long way, and we did have to build a framework on top of Cuba, very specific to the project’s specification. We are still maintaining its code and it’s rather simple to do so. We’ve had no performance issues at all on the server side, even when testing with a large user base, so we’re really satisfied with what we’ve built. Microframeworks are here to stay, and they are not only for hackers to play around with, they are ready for business.