Why Roda?

Roda has a very useful combination of features that make web development easy. It's designed to be fast, DRY, and correct.

Goals

• Simplicity
• Reliability
• Extensibility
• Performance

Simplicity

Roda is designed to be simple, both internally and externally. It uses a routing tree to enable you to write simpler and DRYer code.

Reliability

Roda supports and encourages immutability. Roda apps are designed to be frozen in production, which eliminates possible thread safety issues. Additionally, Roda limits the instance variables, constants, and methods that it uses, so that they do not conflict with the ones you use for your application.

Extensibility

Roda is built completely out of plugins, which makes it very extensible. You can override any part of Roda and call super to get the default behavior.

Performance

Roda has low per-request overhead, and the use of a routing tree and intelligent caching of internal datastructures makes it significantly faster than popular ruby web frameworks.

Comparison to Sinatra

Routing Tree

The primary difference between Roda and Sinatra is that Roda uses a routing tree, while Sinatra uses a list of routes. At any point in the routing tree, Roda allows you to operate on the current request. If your URLs reflect your application architecture, this allows you to have DRYer code. Let's examine code examples for a very simple app, implemented in both Sinatra and Roda:

require 'roda'

class App < Roda
  plugin :render
  plugin :all_verbs

  route do |r|
    r.root do
      view :index
    end

    r.is 'artist/:id' do |artist_id|
      @artist = Artist[artist_id]
      check_access(@artist)

      r.get do
        view :artist
      end

      r.post do
        @artist.update(r['artist'])
        r.redirect
      end

      r.delete do
        @artist.destroy
        r.redirect '/'
      end
    end
  end
end

require 'sinatra/base'

class App < Sinatra::Base
  get '/' do
    erb :index
  end

  get '/artist/:id' do
    @artist = Artist[params[:id]]
    check_access(@artist)
    erb :artist
  end

  post '/artist/:id' do
    @artist = Artist[params[:id]]
    check_access(@artist)
    @artist.update(params[:artist])
    redirect(request.path_info)
  end

  delete '/artist/:id' do
    @artist = Artist[params[:id]]
    check_access(@artist)
    @artist.destory
    redirect '/' 
  end
end

While the Roda code is slightly longer, it should be apparent that it is actually simpler. Instead of setting the @artist variable and checking that access is allowed in all three of the sinatra routes, the variables are set as soon as that branch of the tree is taken, and can be used in all routes under that branch. This is why Roda is called a routing tree web toolkit. This is a very simplified example, but if you see this type of duplication in a lot of the Sinatra code you write, your app could probably be made simpler by converting to Roda.

Faster

In addition to being more maintainable, Roda's approach is also faster in general. Sinatra routes requests by testing each of the stored routes against the current request, in order. With Roda, once one branch of the tree matches, only routes inside that branch are considered, not any routes after that branch. Roda also has support for a single route that dispatches to multiple branches via the multi_route and multi_run plugins. For large applications, routing in Sinatra is roughly O(N), where N is the number of routes, while routing in Roda can be close to O(log N), depending on how you structure your routing tree. For small applications, because Roda has lower per-request overhead, Roda is about 2.5 times faster than Sinatra.

Plugin System

Another difference between Roda and Sinatra is that Roda has a very small core, with a plugin system modeled on Sequel's. All parts of Roda (class/instance/request/response) can be overridden by plugins and call super to get the default behavior. This includes when plugins are applied to the Roda class itself (affecting all subclasses). The reason Roda is referred to as a toolkit is that by using different combinations of plugins, you can build the routing tree web framework that meets your needs.

Many features that are built into Sinatra are shipped as plugins in Roda. This way they can easily be used if needed, but if you don't use them you don't pay the cost for loading them. Near the top of the Roda example, you can see plugin :render, which adds support for template rendering, and plugin :all_verbs, which adds routing methods for all HTTP request methods.

Less Pollution

Roda is very concerned about pollution. In this case, pollution of the scope in which the route block operates. Roda purposely limits the instance variables, methods, and constants available in the route block scope, so that it is unlikely you will run into conflicts. If you've ever tried to use an instance variable named @request inside a Sinatra::Base subclass, you'll appreciate that Roda attempts to avoid polluting the scope.

Immutable

In production use, Roda applications are designed to be frozen (using the standard freeze method), which freezes all internal datastructures (except thead-safe caches used at runtime). This avoids possible thread-safety issues when using Roda.