Pros and Cons of Using Sinatra

Since last October, I have been busy developing a commercial inventory management system. This system needed a website, and part of that website managed download access to the system. Much of the site used Jekyll, but Jekyll (being a static content generator) wasn't appropriate for the job. After considering a few different choices, I decided to use Sinatra, a Ruby framework for web development. I have used Sinatra for the last few months, so I have some idea about the pros and cons of using it.

Note

I did not take performance into consideration when choosing Sinatra. I also worked on this app by myself, so I am uncertain about how Sinatra fares in a multi-developer environment.

Pros

1. Small and Focused

2. Easy To Learn

Sinatra is a framework for specifying how to handle HTTP requests. Its focus on HTTP minimizes its dependencies and makes Sinatra relatively easy to learn when compared to larger frameworks like Ruby on Rails, Django, and ASP.NET MVC.

The official introduction covers much of what you need to know. If you are already fluent in Ruby and use tools like Rake, code written with Sinatra should look familiar.

3. Easy to Use

The basics of Sinatra are easy to pick-up, at least for developers with web experience. Here's an example of a single-page app in Sinatra:

require 'sinatra'

get '/' do
    erb :index
end

This single-route app handles GET requests at the website's root. Its response renders an ERB template found at 'views/index.erb' (denoted by the symbol ':index') and return the rendered string. More complex stuff, like error-handling and display of error pages, is similarly easy

4. Works Well With Many Ruby Libraries

Sinatra does not include its own ORM for database access, templating engine, or testing framework. This gives developers freedom to use libraries that will best fit their needs. I personally think that Sequel (an ORM) goes very well with Sinatra. Both have a bit in common: their names begin with an 'S', both have few dependencies, and both are simplistic but powerful. REST Client is directly inspired by Sinatra, and works well within a Sinatra app.

Your template language of choice likely has built-in support.

As far as other libraries goes, it will probably work unless it depends on Ruby on Rails or some part of RoR that you are not using (like Active Record).

Cons

1. Lacks HTML Helper Methods

Sinatra's focus is HTTP, not HTML. Unlike Ruby on Rails, it does not include many helpers for generating HTML.

To my knowledge, Sinatra only has one built-in helper that is useful in views: url(), which helps generate proper URLs for your app. If hand-writing form markup is not your idea of a fun time, you have three choices: write your own helper, use a third party's helper, or use a different web framework.

Sinatra might be a bad fit for developers looking for a web framework that actively assists with writing HTML.

2. Header Issues

Using Chrome's developer tools to audit my site, I saw many errors and warnings concerning HTTP Headers. The problems involved cookie-setting headers (which were implicitly added when adding sessions to my app) and cache-control headers (which were added using Sinatra's header helpers). These issues were the cause of a few headaches.

3. Deployment Can Be Tricky

http://sinatra-book.gittr.com/ has a section on deployment, but it only covers Heroku. I was hesitant to use Heroku because I could not determine the limits of their free plan, and Heroku does not have an inexpensive paid plan.

Sinatra Recipies provides a bit more information about deploying to other platforms, but does not go into specifics about deployment automation.

Most of my deployment woes came from automating deployment. I chose to use rbenv: that caused deploy script-related issues, but at least that gave me the opportunity learn a lot about Capistrano, Fabric, and shell scripting. I chose to run my server as a user: that required writing a custom startup script. After much work, I was able to deploy my Sinatra app to production and write a script to automate the process.

It's certainly different from deploying ASP.NET MVC applications. I could upload files to a server and let IIS take care of the rest.

4. You Determine File Structure

One could create a full Sinatra app (including template content for views) in a single file. This is great for small sites or APIs, but larger projects should span multiple files. Sinatra does not dictate how developers should separate parts of the app, like data-related logic and presentation.

For my site, all of the data model classes go in a separate file and module. You might prefer to put data models in multiple files. You might even want to separate your app into pieces. Code structure may differ for each Sinatra application, and there does not seem to be any best practices for code layout.

Conclusion

Sinatra worked for what I used it for. I recommend checking it out.


Padrino expands on Sinatra and is more comparable to Ruby on Rails. I personally don't use it, but you can check it out if you are intimidated by Sinatra's barebones nature but still want to use it in a project.