Sinatra is not a framework but a library i.e. a set of classes that allows you to build almost any kind of web-based solution (no matter what the complexity) in a very simple manner, on top of the abstracted HTTP layer it implements from Rack. When you code in Sinatra you’re bound only by HTTP and your Ruby knowledge. Sinatra doesn’t force anything on you, which can lead to awesome or evil code, in equal measures.
Sinatra apps are typically written in a single file. It starts up and shuts down nearly instantaneously. It doesn’t use much memory and it serves requests very quickly. But, it also offers nearly every major feature you expect from a full web framework: RESTful resources, templating (ERB, Haml/Sass, and Builder), mime types, file streaming, etags, development/production mode, exception rendering. It’s fully testable with your choice of test or spec framework. It’s multithreaded by default, though you can pass an option to wrap actions in a mutex. You can add in a database by requiring ActiveRecord or DataMapper. And it uses Rack, running on Mongrel by default.
Blake Mizerany the creator of Sinatra says that it is better to learn Sinatra before Ruby on Rails:
When you learn a large framework first, you’re introduced to an abundance of ideas, constraints, and magic. Worst of all, they start you with a pattern. In the case of Rails, that’s MVC. MVC doesn’t fit most web-applications from the start or at all. You’re doing yourself a disservice starting with it. Back into patterns, never start with them- Reference here
The simplest way to obtain Sinatra is through Rubygems. Open a command window in Windows and type:
c:> gem install sinatra
Linux/OS X the command would be:
sudo gem install sinatra
Installing its Dependencies
- Sinatra depends on the Rack gem which gets installed along with Sinatra.
- Installing Mongrel (a fast HTTP library and server for Ruby that is intended for hosting Ruby web applications of any kind using plain HTTP – http://mongrel.rubyforge.org/) is quite simple. In the already open command window, type:
c:> gem install mongrel
What are Routes?
The main feature of Sinatra is defining ‘routes’ as an HTTP verb for a path that executes an arbitrary block of Ruby code. Something like:
verb ‘path’ do
... # return/render something
Sinatra’s routes are designed to respond to the HTTP request methods (GET, POST, PUT, DELETE).
In Sinatra, a route is an HTTP method paired with an URL matching pattern.
These URL handlers (also called “routing”) can be used to match anything from a static string (such as /hello) to a string with parameters (/hello/:name) or anything you can imagine using wildcards and regular expressions.
Each route is associated with a block. Let us look at an example:
get '/' do
.. show something ..
get '/hello/:name' do
# The /hello portion matches that portion of the URL from the
# request you made, and :name will absorb any other text you
# give it and put it in the params hash under the key :name
post '/' do
.. create something ..
put '/' do
.. update something ..
delete '/' do
.. delete something ..
Routes are matched in the order they are defined.
When a new request comes in, the first route that matches the request is invoked i.e. the handler (the code block) attached to that route gets executed. For this reason, you should put your most specific handlers on top and your most vague handlers on the bottom.
A tiny web-application
Here’s an example of a simple Sinatra application. Write a Ruby program myapp1.rb and store it in the folder:
Though the name of the folder is c:>sinatra_programs, we are going to have only one Sinatra program here.
The program is:
Sinatra applications can be run directly:
ruby myapp1.rb [-h] [-x] [-e ENVIRONMENT] [-p PORT] [-s HANDLER]
The above options are:
- -h # help
- -p # set the port (default is 4567)
- -e # set the environment (default is development)
- -s # specify rack server/handler (default is thin)
- -x # turn on the mutex lock (default off) – currently not used
In the article- http://gist.github.com/54177, it states that using: require ‘rubygems’, is wrong. It is an environmental issue and not an app issue. The article mentions that you might It is an environmental issue and not an app issue. The article mentions that you might use: ruby -rubygems myapp1.rb
Another way is to use RUBYOPT. Refer article – http://rubygems.org/read/chapter/3.
By setting the RUBYOPT environment variable to the value rubygems, you tell Ruby to load RubyGems every time it starts up. This is similar to the -rubygems options above, but you only have to specify this once (rather than each time you run a Ruby script).