Video: Sinatra At Boston.rb, Part 3

Video: Sinatra At Boston.rb, Part 3

This is the third in a series of short videos. They feature Blake Mizerany discussing Sinatra and Heroku in great technical detail at September’s Boston.rb. Watch Part 1 and Part 2 if you’d like.

Legacy APIs

Blake uses “legacy APIs” as a common use case for Sinatra. The reason params[:splat] and params[:matches] and super-flexible routing in Sinatra exists is because of work done on an existing non-RESTful, ugly API that sent all the data back in the URL itself (not in JSON or some other format).

This seems to be consistent with the philosophy of “Don’t fear the URLs”.

Return values must respond to “each”

In order to be Rack-compliant, your return values of Sinatra routes should respond to each. Blake mentions the Ruby 1.9 gotcha that the Rack spec also mentions:

The Body must respond to each and must only yield String values. The Body should not be an instance of String, as this will break in Ruby 1.9. If the Body responds to close, it will be called after iteration. If the Body responds to to_path, it must return a String identifying the location of a file whose contents are identical to that produced by calling each. The Body commonly is an Array of Strings, the application instance itself, or a File-like object.

Templates

get '/' do
  erb(:index)
end

The file would be named “index.erb”. Sintra doesn’t use the same “name.format.template” convention because the routes are supposed to be “less magical”. You should know what your response format is based on which route you’re already in.

begin/rescue vs. throw :halt

I hadn’t seen a discussion of these two control structures before. begin/rescue is meant for exceptions and throw :halt is meant for returning a value and returning to another section of code.

The promise is that this will come in very handy as we dive deeper into Sinatra.

get '/' do
  halt(404) unless session[:user]
  # ...
end

As Sinatra processes the route, it’s listening for halts and passes.

When Sinatra, When Rails?

I cut a section out for space reasons where Blake talks about thanking David Heinemeier Hansson for writing Rails. Blake had been trying to get Ruby into companies for years without much success, then Rails came along and made it acceptable.

Rails:

  • get bigger apps going quickly
  • less pain to get a CRUD app going

Sinatra:

  • more control
  • choose your own conventions
  • legacy APIs
  • small apps going quickly
  • take full advantage of Rack, no special magic to be compatible

Shotgun

At the end of this video, I included a section where Blake shows, in response to an audience question, how to append to an existing body via response.body.

I thought his shotgun command was more interesting, though.

Shotgun is “an automatic reloading version of the rackup command that’s shipped with Rack.” It gets you “application-wide reloading of all source files and templates on each request” by forking into a child process, processing, then exiting the child process.

Note that this is not part of Sinatra at all. This is obviously great for a development environment, but keeps Sinatra clean by being a third party.

Dan Croak Developer

Sharpen your programming skills by completing coding exercises that are reviewed by other developers at Upcase today.