z, ?	toggle help (this)
space, →	next slide
shift-space, ←	previous slide
d	toggle debug mode
## <ret>	go to slide #
r	reload slides
n	toggle notes

loading presentation...

Hello everyone! I'm super happy to be here at RubyConf to talk about Roda. Roda is a web toolkit that I launched in 2014. I had the pleasure of presenting the newly launched Roda at RubyConf 2014, and it's great to be back at RubyConf, 10 years later, to discuss Roda's progress. In this presentation, I'll be going over the advantages of using Roda, discussing the progress made in the 10 years since launch, and looking at how some open source software uses Roda.

10 Years of Roda

RubyConf 2024

My name is Jeremy Evans. I maintain Roda and many other Ruby libraries. I am also a Ruby committer who focuses on fixing bugs in Ruby.

GitHub: jeremyevans

Twitter: @jeremyevans0

Additionally, I am the author of Polished Ruby Programming, a book aimed at intermediate Ruby programmers.

Before discussing the first 10 years of Roda,

10 Years of Roda

I'm going to dive right into a simple Roda example, in case you are not familiar with it. While a little more complex than hello world, this example shows Roda's key advantage over other Ruby web frameworks, which is the ability to handle requests during routing, instead of separating the routing process from the request handling process.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

With Roda, all requests to the application are yielded to the route block. The route block is responsible for handling all requests. By convention, Roda uses r as the route block variable.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

At any point in the route block, you can do processing related to the request. For example, if you want to check access by IP, you could have that check at the top of your route block. This would be the equivalent of an application-level before hook in other frameworks.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Assuming we pass the access check, we get to the first routing method. The r.on method is used to handle branches in the routing tree.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

In this example, the r.on method is passed two arguments, called matchers.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The first is the string employee, which will match if the next segment in the remaining path is employee.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The second is the class Integer, which will match if the next segment in the remaining path is an integer.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

So if we look at the combination of these two matchers.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

They will match a request path such as /employee/7.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
  # Matches:
  # /employee/7

Since the entire request path has been consumed by the two matchers, the remaining path is empty.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
  # Matches:
  # /employee/7 # with remaining path ""

the matchers will also match a request path such as /employee/7/name.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
  # Matches:
  # /employee/7 # with remaining path ""
  # /employee/7/name

The remaining path after this would be /name, which is what routing methods inside this block will operate on.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
  # Matches:
  # /employee/7 # with remaining path ""
  # /employee/7/name # with remaining path "/name"

It would not match a path such as /vendor/9, since the first segment is not employee.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
  # Matches:
  # /employee/7
  # /employee/7/name
  #
  # Does Not Match:
  # /vendor/9

It would also not match a path such as /employee/name, since name is not an integer.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
  # Matches:
  # /employee/7
  # /employee/7/name
  #
  # Does Not Match:
  # /vendor/9
  # /employee/name

If the request does not match the r.on call, r.on will return nil without yielding to the block.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

In this example, it would reach the end of the route block, resulting in a 404 response, because the request was never handled.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

If the request does match the r.on call, it will yield to the provided block.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Because the Integer class matcher was used,

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The block will be yielded that segment of the request path, converted to an integer.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

For a GET request for /employee/7/name

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The employee_id block variable will be the integer 7.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id| # 7
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Inside the block, the first line is this code, which shows the primary advantage of Roda, which is that at any point during routing, you can do processing related the request. In this case, we are using that employee_id block variable to look up the employee by id, and then setting the employee variable. All routes under this block can then access the employee.|You can get similar behavior in other frameworks using before hooks, but this provides a simpler approach that avoids indirection. If you have ever had to debug issues involving the use of before hooks, I think you can appreciate this approach.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

What if there is no matching employee for the id?

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

In that case, you can use the next keyword to return nil from the block, which Roda will treat as a 404 response.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

This ensures that there is a valid employee for the rest of the block.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The next routing method is r.is with a string name matcher. r.is is similar to r.on, except that it requires the request path be fully consumed after all matchers have been applied.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

For our request, since the employee and 7 segments have already been consumed, the remaining path is /name.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The string name matcher will match that segment.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Since the entire request path has now been consumed by the matchers given to the routing methods,

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

the r.is method will match, and it will yield to the block.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Inside the r.is block, the first method call is r.get, which will match,

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

because the request being handled uses the GET request method.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The r.get block returns the string Hello followed by the employee's name. As the block returns a string, this string will be used as the response body.

Roda.route do |r| # GET /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Let's see how a POST request to the same path will be handled.

Roda.route do |r| # POST /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The path of the request will still be fully consumed by the matchers given to the r.on and r.is methods.

Roda.route do |r| # POST /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

However, the r.get method call will not match, as this is a POST request and not a GET request. So r.get will return nil without yielding to the block.

Roda.route do |r| # POST /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The next method call in the block is r.post, which will match, since this request is a POST request.

Roda.route do |r| # POST /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

So r.post will yield to the block. In this case, we will use the name parameter to update the employee's name.

Roda.route do |r| # POST /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Then we will redirect the request. Since no arguments are given, this will redirect to the same path, but using a GET request and not a POST request.

Roda.route do |r| # POST /employee/7/name
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Hopefully, this example was able to give you a basic idea about how Roda's routing tree works.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The most important part to remember, is that Roda gives you the power to do processing related to the request at any point during the routing process, which reduces duplication and indirection, and results in applications that are simpler and easier to understand.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Simplicity is one of Roda's four goals. After 10 years developing Roda, I still think that the primary benefit of Roda is it allows the same application to be built more simply than in other frameworks.

Simplicity

Another of Roda's goals is performance. Unlike the simplicity goal, where the benefits are subjective, you can see objective differences between the performance of Roda and other web frameworks. We'll look at two benchmarks.

Performance

The first is r10k, a synthetic benchmark which measures per-request overhead and scalability for large numbers of routes. r10k benchmarks applications with 10, 100, 1000, and 10,000 routes. To avoid web server overhead, it tests using the rack API directly.

r10k

Here are the request per second results for Roda, Rails, Sinatra, Hanami, and Camping. It shows Roda is much faster than other frameworks. Unfortunately, The scale of the graph makes it difficult to see how the other frameworks compare.

Here's the same graph, but using a logarithmic scale. This still shows Roda as much faster, but it also shows that Roda, Rails, and Hanami all scale well to large numbers of routes. It shows that Sinatra and Camping do not scale well for large numbers of routes, which is because both use a linear search of routes during request handling.

r10k also provides memory benchmarks. These show that Roda uses less memory than other frameworks. Rails uses about 3 to 4 times more memory than Roda in this benchmark.

While the r10k benchmarks are useful, they don't tell you much about real world performance differences.

r10k

For that, the TechEmpower web framework benchmarks do a better job. TechEmpower has been benchmarking web frameworks in many languages for over 10 years. Roda has led the Ruby web framework benchmarks ever since it was added in 2017.

TechEmpower

Here are the composite score results of the most recent round of TechEmpower benchmarks for Ruby web frameworks. Roda leads in every category. The weighted score for Roda is almost double the weighted score for Rails. This lines up with results I've seen in applications converted from Rails to Roda, where the converted Roda application is about twice as fast.

As the benchmarks show, Roda achieves its performance goal. It's is the fastest Ruby web framework, scales well, and uses the least memory.

Performance

It is the fastest framework mostly because it has the lowest per-request overhead. Roda is designed to minimize the amount of work between when it receives the rack request environment and when it starts processing the routing tree.

Fastest

Roda scales well because it uses a routing tree. As soon as a branch of the routing tree is taken, other branches at the same level are no longer considered.

Scales

Well

Finally, Roda uses the least amount of memory because it is designed around a small core. The small core handles basic routing and request handling.

Least

Memory

All other features are added via plugins. Roda's core is itself a plugin. Plugins can override any part of core Roda and any previously loaded plugins.

Plugins

As an example of its minimalism, Roda's core does not include template rendering. Template rendering is supported via a plugin. It's common to use this plugin when developing applications targetting browsers. However, if you are designing an application that just serves API responses via JSON, you wouldn't need it.

Template

Rendering

In that case, you would want to use the JSON plugin, which allows route blocks to return arrays or hashes, and have those converted to JSON and used as response bodies.

JSON

The reason I refer to Roda as a toolkit is you can think of each plugin as a tool. Different applications require different tools, and with Roda, you only pay the overhead cost for the tools you choose to use. Roda ships with over 120 plugins to handle the needs of a wide variety of web applications, and there are numerous external Roda plugins to handle additional needs.

Toolkit

This approach of having a small core, and shipping all optional features as plugins is how Roda achieves its goal of extensibility.

Extensibility

Roda's final goal is reliability. Roda achieves this goal by combining two development approaches.

Reliability

The first development approach is immutability. Roda applications are designed to be frozen in production and when testing. This reduces the possibility for thread safety issues, as well as memory leaks due to unexpected object retention.|Immutability is not just for reliability in Roda either.

Immutability

In Roda, immutability also improves performance. When you freeze your Roda application, Roda knows there will be no future configuration changes to it. Roda then determines whether methods designed for extensibility have not been overridden, and in that case, it overrides the default extensible methods with optimized methods. This gives you the best of both worlds. Extensibility when you need it, and maximum performance when you don't.

Immutability

→ Performance

The second development approach related to reliability I refer to as pollution control.

Pollution

Control

More explicitly, namespace pollution control. Roda limits pollution of your constant, method, and instance variable namespaces inside your application.

Namespace

Pollution

Control

All internal constants in the Roda class start with Roda, to avoid conflicting with user-defined constants.

Constants

Roda limits instance variable pollution by prefixing all internal instance variables in route block scope with an underscore. If you've ever developed a Sinatra application and tried to use request or response instance variables, you will appreciate this.

Instance

Variables

Roda limits method pollution by defining only 6 methods in Roda block scope, beyond the methods defined in Object and some private methods that begin with an underscore. This makes it less likely a user-defined method will conflict with a Roda method.

Methods

Now that I've given you a brief taste of Roda and discussed how Roda achieves its goals,

Roda

I can start discussing the first 10 years of Roda. Roda's first release was on July 30, 2014, and it's most recent release, the 125th release, was three days ago.

10 Years of Roda

I don't like waiting long to use new features, so Roda follows a simple to understand release schedule. There is a new Roda release every month, around the middle of the month, ever since 2014.

New Release

Every Month

I also don't like when changes to a library break my applications, so Roda places a high priority on backwards compatibility.

Backwards

Compatibility

I think the compatibility is so good that the majority of applications that worked with the first release, Roda 0.9, would still work if you upgraded them to latest release, Roda 3.86, with one main exception.

Almost 100%

Compatibility

If we go back to our first example,

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

We see that it uses the Integer class matcher. However, Roda did not support using the Integer class as a matcher until Roda 2.27.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Before Roda 2.27, this type of matcher would generally be written using what is referred to as a placeholder string, with placeholders in the string being prefixed by a colon. However, this style resulted in two issues.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee/:employee_id" do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

First, it resulted in redundancy. Most developers would name the placeholders similar to the block variables. This isn't technically a problem, but it is a tad annoying.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee/:employee_id" do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

The actual problem was a performance problem, which is that you needed to scan all strings used as matchers to see if they contain placeholders, and treat the string differently if it had a placeholder. Strings are the most common type of matcher, so this check resulted in a measurable slowdown even if you weren't using placeholders.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee/:employee_id" do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Roda 3 removed support for placeholders in string matchers by default. In order to support backwards compatibility, Roda 3 shipped with a placeholder_string_matchers plugin.|I analyzed a couple of my open source applications, checking out the commit where the application was converted from Sinatra or Rails to Roda 0.9, and trying it with the current version of Roda. In both cases, adding the placeholder_string_matchers plugin was the only Roda-related change needed to get the specs passing with the current version of Roda.

Roda.plugin :placeholder_string_matchers

I mentioned that one of the reasons for breaking backwards compatibility was to improve performance. How much did this change and other changes improve Roda's performance over the last 10 years?

Performance

To determine that, we're going to look at some more r10k benchmark results, to see how Roda's performance has improved over time. Additionally, as Roda is a fork of another web framework named Cuba, we're also going to compare Roda to Cuba.

r10k

Let's start with Roda's initial release, compared against the current Cuba release at the time. As you can see, the performance is basically the same. For the initial release, I was focused on differences in the route block handling, handling block responses, and getting the plugin system working. I wasn't focused on performance, since Cuba was already much faster than other Ruby web frameworks at the time.

Less than a month after the initial release, I released Roda 1.0. This had a massive boost in performance over the initial release, with a number of additional optimizations. At the time, most matchers in Roda were based on regular expression scanning, and the most important optimization was the caching of the regular expressions, instead of generating a new regular expression for every matcher.

About 6 months after releasing Roda 1.0, I released Roda 2.0, which improved performance over 1.0 by about 20%. This performance improvement was due to reducing allocations and operations during matching, so that each match attempt did not modify the request environment.

About two and a half years after that, I released Roda 3.0, which improved performance over 2.0 by about 40%. This performance improvement was mostly due to avoiding regular expressions during matching, and the removal of placeholders during string matching. Instead of regular expressions, string methods such as start_with? and index are used. This idea was taken from syro, a routing library by the same author as Cuba.

By January 2021, with the release of Roda 3.40, performance had increased another 15%. The performance increase was due to a couple of optimizations. During this time period is when I added the optimization during application freezing. Additionally, the performance of string and segment matching was improved by about 15%, and terminal matching by about 400%.

Between Roda 3.40 and 3.60, performance increased another 30%. This was due to additional optimizations on the most common matchers. Roda's current performance is about the same as 3.60.|Between Roda's initial release and the current release, performance in this benchmark improved by a factor of 12. I think that's pretty amazing considering that even at Roda's initial release, it was one of the fastest frameworks. However, this isn't the limit of Roda's performance.

Using the optimized_string_matchers, optimized_segment_matchers, and plain_hash_response_headers Roda plugins, performance can be improved an additional 35%. This does require some small sacrifices in usability, though.

r10k is a routing and per-request overhead benchmark, and Roda has improved greatly over the years at those. However, that's not the only way Roda has improved performance.

Performance

Many of the plugins that ship with Roda have been optimized as well.

Plugin

Performance

For example, the render plugin has shipped with every release of Roda, but it and other related plugins were extensively optimized a few years ago. For simple templates, the render plugin is about 4 times faster than it was originally.

render

Plugin

Performance

Speaking of plugins,

Plugins

Roda 0.9.0 shipped with 15 plugins.

Roda 0.9.0

Plugins: 15

Roda 3.86 ships with over 120 plugins, more than 8 times as many as the initial release.

Roda 3.86.0

Plugins: 120+

I'm going to take you on a quick tour of the last 10 years of Roda plugins

10 Years of Roda

Plugins

In the initial release, in addition to rendering, Roda shipped with plugins for

Roda 0.9.0

Plugins

handling exceptions,

Roda 0.9.0

Plugins


plugin :error_handler

customizing default headers and

Roda 0.9.0

Plugins


plugin :error_handler
plugin :default_headers

404 responses,

Roda 0.9.0

Plugins


plugin :error_handler
plugin :default_headers
plugin :not_found

handling flash messages,

Roda 0.9.0

Plugins


plugin :error_handler
plugin :default_headers
plugin :not_found
plugin :flash

streaming responses,

Roda 0.9.0

Plugins


plugin :error_handler
plugin :default_headers
plugin :not_found
plugin :flash
plugin :streaming

and operating as rack middleware. However, one of most important plugins was the ability to use separate routing blocks.

Roda 0.9.0

Plugins


plugin :error_handler
plugin :default_headers
plugin :not_found
plugin :flash
plugin :streaming
plugin :middleware

If you remember back to our initial example.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

I mentioned that all requests are yielded to the route block, and the route block determines the response. In Ruby, you cannot split a block between multiple files, and having all routes in a single file only makes sense for small applications. To handle large applications, you need a way to separate the route block.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Even the very first release of Roda supported that, via the multi_route plugin.

Roda.plugin :multi_route

Roda.route do |r|
  access_check!(r.ip)
  r.multi_route
end

With the multi_route plugin, you could call r.multi_route in your main routing block, and it would dispatch to separate routing blocks based on the next segment in the remaining path.

Roda.plugin :multi_route

Roda.route do |r|
  access_check!(r.ip)
  r.multi_route
end

Those routing blocks would generally be stored in separate files based on the route segment name, like this. This made it simple to organize large applications in Roda, and allowed even the first release of Roda to scale from simple single file applications to decent sized applications.

Roda.route("employee") do
  r.on Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Roda 1.0 added 11 new plugins not in the initial release. These included plugins for

Roda 1.0.0

Plugins

returning arrays and hashes as json,

Roda 1.0.0

Plugins


plugin :json

cross site request forgery protection,

Roda 1.0.0

Plugins


plugin :json
plugin :csrf

rendering a collection of partials in one call,

Roda 1.0.0

Plugins


plugin :json
plugin :csrf
plugin :render_each

and having a separate view subdirectory for separate branches of the routing tree.

Roda 1.0.0

Plugins


plugin :json
plugin :csrf
plugin :render_each
plugin :view_subdirs # now :view_options

Additionally, the render plugin was expanded to support the automatic escaping of output in templates, greatly reducing the likelihood of cross site scripting issues.

Roda 1.0.0

Plugins


plugin :json
plugin :csrf
plugin :render_each
plugin :view_subdirs # now :view_options
plugin :render, escape: true

I think my favorite plugin addition in 1.0 is symbol_views. The symbol_views plugin is very simple, but it allows you to replace manual calls to view to render templates,




route do |r|
  r.get do
    view('employee')
  end
end

and just have the route block return a symbol. This small change DRYs up a lot of route code, and makes the common case of rendering a template inside a layout even simpler than it is in Sinatra or Rails.|Now, not everyone is in favor of this terse style. However, just because I think a particular style is nicer does not mean I think I should force it on all Roda users.


plugin :symbol_views

route do |r|
  r.get do
    :employee
  end
end

Between Roda 1.1 and 1.3, 25 more plugins were added, including plugins for

Roda 1.1-1.3

Plugins

managing HTTP caching,

Roda 1.1-1.3

Plugins


plugin :caching

incrementally rendering templates,

Roda 1.1-1.3

Plugins


plugin :caching
plugin :chunked

and compiling, compressing, and serving asset files.

Roda 1.1-1.3

Plugins


plugin :caching
plugin :chunked
plugin :assets

Roda 1.2 added the mailer plugin, which brought the benefit of routing trees to sending emails from applications.


  plugin :mailer

Here's an example that uses the mailer plugin.

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views

  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

Generally, you use the mailer plugin in a Roda subclass designed specifically for sending emails.

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views

  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

Unlike a Roda web application, which is designed to handle HTTP requests, a Roda mail application is designed to handle internal requests. However, sending mail with the mailer plugin is done by providing a path, just like with an HTTP request.

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views
  # Mailer.sendmail("/employee/7/time_off")
  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

A Roda mail application uses the same basic routing methods that a Roda web application uses.

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views
  # Mailer.sendmail("/employee/7/time_off")
  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

Just like in a Roda web application, at any point when handling a mail request, the Roda mail application can do processing related to the mail. Here, we are setting the sender and recipient addresses, so they don't need to be duplicated inside every mail handling block.

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views
  # Mailer.sendmail("/employee/7/time_off")
  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

The r.mail method is used to handle mail routes, and operates similarly to r.get and r.post.

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views
  # Mailer.sendmail("/employee/7/time_off")
  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

In this case, the time_off matcher matches the remaining path,

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views
  # Mailer.sendmail("/employee/7/time_off")
  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

so the method will yield to the block. The block sets the subject for the mail, and returns the symbol for the mail template to render.

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views
  # Mailer.sendmail("/employee/7/time_off")
  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

Returning a symbol works because this mail application also uses the symbol_views plugin.

class Mailer < Roda
  plugin :mailer
  plugin :render
  plugin :symbol_views
  # Mailer.sendmail("/employee/7/time_off")
  Roda.route do |r|
    r.on "employee", Integer do |employee_id|
      no_mail! unless employee = Employee[employee_id]

      from "app@example.com"
      to employee.email

      r.mail "time_off" do
        subject "Time Off Request Approved"
        :time_off
      end

      r.mail "expense_claim" do
        subject "Expense Claim Approved"
        :expense_claim
      end
    end
  end
end

Between Roda 2.0 and 2.29, 22 more plugins were added. These included support for

Roda 2.0-2.29

Plugins

sending preload headers for assets,

Roda 2.0-2.29

Plugins


plugin :assets_preloading

serving public files at specific places in the routing tree,

Roda 2.0-2.29

Plugins


plugin :assets_preloading
plugin :public

rewriting paths prior to routing,

Roda 2.0-2.29

Plugins


plugin :assets_preloading
plugin :public
plugin :path_rewriter

parsing JSON request bodies to parameters,

Roda 2.0-2.29

Plugins


plugin :assets_preloading
plugin :public
plugin :path_rewriter
plugin :json_parser

fast O(1) routing to static paths,

Roda 2.0-2.29

Plugins


plugin :assets_preloading
plugin :public
plugin :path_rewriter
plugin :json_parser
plugin :static_routing

and having the routing tree support file extensions in the request path specially.

Roda 2.0-2.29

Plugins


plugin :assets_preloading
plugin :public
plugin :path_rewriter
plugin :json_parser
plugin :static_routing
plugin :type_routing

Roda 2.27 added a class_matchers plugin, which allows you to specify handling of arbitrary classes used as matchers.

plugin :class_matchers

Going back to our initial example,

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

We see that we are using the Integer matcher, which yields an integer.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

We are then looking up the employee using the integer,

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

and have to manually handle the case where the lookup fails.

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Using the class matchers plugin, we can simplify this.

Roda.plugin :class_matchers

Roda.class_matcher Employee, Integer do |employee_id|
  Employee[employee_id]
end

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Employee do |employee|
    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

We can register the Employee class as a matcher, and build on top of the Integer matcher.

Roda.plugin :class_matchers

Roda.class_matcher Employee, Integer do |employee_id|
  Employee[employee_id]
end

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Employee do |employee|
    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

If there is a match by the Integer matcher, the value is yielded to the block as an integer.

Roda.plugin :class_matchers

Roda.class_matcher Employee, Integer do |employee_id|
  Employee[employee_id]
end

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Employee do |employee|
    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

This block can do the employee lookup.

Roda.plugin :class_matchers

Roda.class_matcher Employee, Integer do |employee_id|
  Employee[employee_id]
end

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Employee do |employee|
    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

This allows the routing tree to be simpler. Every case where you are trying to match an employee, you can pass the Employee class as a matcher, and it will yield the Employee object to the routing block if the segment was for a valid employee. If the segment was not for a valid employee, it just wouldn't match.

Roda.plugin :class_matchers

Roda.class_matcher Employee, Integer do |employee_id|
  Employee[employee_id]
end

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Employee do |employee|
    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Between Roda 3.0 and 3.29, 12 more plugins were added, including support for

Roda 3.0-3.29

Plugins

encrypted sessions,

Roda 3.0-3.29

Plugins


plugin :sessions

early hints,

Roda 3.0-3.29

Plugins


plugin :sessions
plugin :early_hints

content security policies,

Roda 3.0-3.29

Plugins


plugin :sessions
plugin :early_hints
plugin :content_security_policy

processing incoming emails using a routing tree,

Roda 3.0-3.29

Plugins


plugin :sessions
plugin :early_hints
plugin :content_security_policy
plugin :mail_processor

logging in common log format,

Roda 3.0-3.29

Plugins


plugin :sessions
plugin :early_hints
plugin :content_security_policy
plugin :mail_processor
plugin :common_logger

showing nice exception handling pages in development,

Roda 3.0-3.29

Plugins


plugin :sessions
plugin :early_hints
plugin :content_security_policy
plugin :mail_processor
plugin :common_logger
plugin :exception_page

splitting the routing tree into sub trees without using regular expressions,

Roda 3.0-3.29

Plugins


plugin :sessions
plugin :early_hints
plugin :content_security_policy
plugin :mail_processor
plugin :common_logger
plugin :exception_page
plugin :hash_routes

and supporting stronger cross site request forgery protection, using tokens specific to the request method and path.

Roda 3.0-3.29

Plugins


plugin :sessions
plugin :early_hints
plugin :content_security_policy
plugin :mail_processor
plugin :common_logger
plugin :exception_page
plugin :hash_routes
plugin :route_csrf

Roda 3.3 added a typecast_params plugin for handling the typecasting of submitted parameters to expected types

plugin :typecast_params

Here's an example of use, showing automatic conversion of a given parameter to a positive integer, ensuring that attackers cannot try to submit an array or hash. typecast_params has support for nested parameters, typecasting arrays of values to specific types, and custom parameter types. It's designed to be simple and not verbose.


  employee_id = typecast_params(:pos_int, "employee_id")

Between Roda 3.30 and 3.59, 17 more plugins were added. These included support for

Roda 3.30-3.59

Plugins

host authorization,

Roda 3.30-3.59

Plugins


plugin :host_authorization

trying multiple render engines and

Roda 3.30-3.59

Plugins


plugin :host_authorization
plugin :additional_render_engines

multiple view directories when rendering templates,

Roda 3.30-3.59

Plugins


plugin :host_authorization
plugin :additional_render_engines
plugin :additional_view_directories

using abitrary objects as matchers during routing,

Roda 3.30-3.59

Plugins


plugin :host_authorization
plugin :additional_render_engines
plugin :additional_view_directories
plugin :custom_matchers

supporting multiple directories for public file serving at different places in the routing tree,

Roda 3.30-3.59

Plugins


plugin :host_authorization
plugin :additional_render_engines
plugin :additional_view_directories
plugin :custom_matchers
plugin :multi_public

and simpler approach to dispatching to separate routing trees,

Roda 3.30-3.59

Plugins


plugin :host_authorization
plugin :additional_render_engines
plugin :additional_view_directories
plugin :custom_matchers
plugin :multi_public
plugin :hash_branches

which can automatically set the view subdirectory during the dispatch.

Roda 3.30-3.59

Plugins


plugin :host_authorization
plugin :additional_render_engines
plugin :additional_view_directories
plugin :custom_matchers
plugin :multi_public
plugin :hash_branches
plugin :hash_branch_view_subdir

Between Roda 3.60 and the current version, 3.86, 19 more plugins were added. These plugins added support for

Roda 3.60-3.86

Plugins

handling arbitrary objects returned from route blocks,

Roda 3.60-3.86

Plugins


plugin :custom_block_results

autoloading hash branches for faster development and testing,

Roda 3.60-3.86

Plugins


plugin :custom_block_results
plugin :autoload_hash_branches

setting a permissions policy,

Roda 3.60-3.86

Plugins


plugin :custom_block_results
plugin :autoload_hash_branches
plugin :permissions_policy

enforcing cookie flags,

Roda 3.60-3.86

Plugins


plugin :custom_block_results
plugin :autoload_hash_branches
plugin :permissions_policy
plugin :cookie_flags

handling invalid request bodies,

Roda 3.60-3.86

Plugins


plugin :custom_block_results
plugin :autoload_hash_branches
plugin :permissions_policy
plugin :cookie_flags
plugin :invalid_request_body

and measuring line and branch coverage of templates, even in Ruby versions that do not support coverage for evaled code.

Roda 3.60-3.86

Plugins


plugin :custom_block_results
plugin :autoload_hash_branches
plugin :permissions_policy
plugin :cookie_flags
plugin :invalid_request_body
plugin :render_coverage

Roda 3.79 added an hmac_paths plugin, which allows you to easily prevent path enumeration by including an HMAC in the path

plugin :hmac_paths

Going back to our initial example,

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

We see that this allows anyone to issue requests for the branch. What if you want to prevent someone with access to the application from enumerating your employees?

Roda.route do |r|
  access_check!(r.ip)
  r.on "employee", Integer do |employee_id|
    next unless employee = Employee[employee_id]

    r.is "name" do
      r.get do
        "Hello #{employee.name}"
      end

      r.post do
        employee.update(name: r.params['name'])
        r.redirect
      end
    end
  end
end

Using the hmac_paths plugin, you can wrap that routing block in r.hmac_path.

Roda.plugin :hmac_paths, secret: ENV['SECRET']

Roda.route do |r|
  access_check!(r.ip)
  r.hmac_path do
    r.on "employee", Integer do |employee_id|
      next unless employee = Employee[employee_id]

      r.is "name" do
        r.get do
          "Hello #{employee.name}"
        end

        r.post do
          employee.update(name: r.params['name'])
          r.redirect
        end
      end
    end
  end
end

When generating paths in your application, you would call the hmac_path method with the path, which would prefix an HMAC and some metadata to the path, such that r.hmac_path will consider it valid. The hmac_paths plugin was expanded in Roda 3.80 to support session specific HMACs, so that paths valid for one logged in user would not work for a different logged in user. It was expanded again in Roda 3.81 to support paths that are only valid for a limited time.

Roda.plugin :hmac_paths, secret: ENV['SECRET']
# hmac_path("/employee/7")
Roda.route do |r|
  access_check!(r.ip)
  r.hmac_path do
    r.on "employee", Integer do |employee_id|
      next unless employee = Employee[employee_id]

      r.is "name" do
        r.get do
          "Hello #{employee.name}"
        end

        r.post do
          employee.update(name: r.params['name'])
          r.redirect
        end
      end
    end
  end
end

So that's a brief tour of plugins Roda has added in its first 10 years.

10 Years of Roda

Plugins

I want to finish up this presentation by briefly discussing two open source applications that are built on top of Roda, and how they are using Roda's features.

Open Source

using Roda

The first application is Karafka-web, which is the web front end for karafka, a Ruby gem for working with Kafka, a distributed publish-subscribe queue.

Karafka-web ships all asset files inside the gem. It uses Roda's public plugin, and serves the assets using a path based on the gem version. This automatically handles cache invalidation, by using a new path for each gem version.

plugin(
  :public,
  root: Karafka::Web.gem_root.join('lib/karafka/web/ui/public'),
  headers: { 'Cache-Control' => 'max-age=31536000, immutable' },
  gzip: true,
  brotli: true
)

route do |r|
  r.on 'assets', Karafka::Web::VERSION do
    r.public
  end

  # ...
end

Karafka-web uses the custom_block_results plugin, so that route blocks can return Karafka-web specific objects, which are translated to HTTP responses. This reduces duplication inside the route blocks.

plugin :custom_block_results

handle_block_result Controllers::Responses::Render do |result|
  render_response(result)
end

handle_block_result Controllers::Responses::Redirect do |result|
  result.flashes.each { |key, value| flash[key] = value }

  response.redirect result.back? ? request.referer : root_path(result.path)
end

handle_block_result Controllers::Responses::File do |result|
  response.headers['Content-Type'] = 'application/octet-stream'
  response.headers['Content-Disposition'] = "attachment; filename=\"#{result.file_name}\""
  response.write result.content
end

The second application is Ubicloud. Ubicloud is an open source alternative to Amazon web services. It's being developed by a startup also named Ubicloud.

Ubicloud uses the Rodauth authentication framework to handle authentication. Rodauth is Ruby's most advanced authentication framework

plugin :rodauth do
  enable :argon2, :change_login, :change_password, :close_account, :create_account,
    :lockout, :login, :logout, :remember, :reset_password,
    :disallow_password_reuse, :password_grace_period, :active_sessions,
    :verify_login_change, :change_password_notify, :confirm_password,
    :otp, :webauthn, :recovery_codes

# ...

end

With built-in support for multifactor authentication such as TOTP and Webauthn.

plugin :rodauth do
  enable :argon2, :change_login, :change_password, :close_account, :create_account,
    :lockout, :login, :logout, :remember, :reset_password,
    :disallow_password_reuse, :password_grace_period, :active_sessions,
    :verify_login_change, :change_password_notify, :confirm_password,
    :otp, :webauthn, :recovery_codes

# ...

end

Rodauth is a Roda plugin, but you can use Rodauth even in non-Roda applications, by using Roda's middleware plugin and using the Roda application as middleware.

plugin :rodauth do
  enable :argon2, :change_login, :change_password, :close_account, :create_account,
    :lockout, :login, :logout, :remember, :reset_password,
    :disallow_password_reuse, :password_grace_period, :active_sessions,
    :verify_login_change, :change_password_notify, :confirm_password,
    :otp, :webauthn, :recovery_codes

# ...

end

Ubicloud uses multiple Rodauth configurations, as it uses Rodauth to handle authentication for both browser logins as well as its JSON API.

plugin :rodauth do
  enable :argon2, :change_login, :change_password, :close_account, :create_account,
    :lockout, :login, :logout, :remember, :reset_password,
    :disallow_password_reuse, :password_grace_period, :active_sessions,
    :verify_login_change, :change_password_notify, :confirm_password,
    :otp, :webauthn, :recovery_codes

# ...

end

plugin :rodauth, name: :api do
  enable :argon2, :json, :jwt, :active_sessions, :login

# ...

end

This is the section of Ubicloud's main route block which designed to handle browser requests and GitHub webhooks.


  r.public
  r.assets

  r.on "webhook" do
    r.hash_branches(:webhook_prefix)
  end

  r.rodauth

  check_csrf!
  rodauth.load_memory
  rodauth.check_active_session

  r.root do
    r.redirect rodauth.login_route
  end
  rodauth.require_authentication

  r.hash_branches("")

Ubicloud is a decent sized application, so it uses the hash_branches plugin to separate routing trees. It actually has two separate dispatches to routing trees. This one is for the main application, and used for logged in users.


  r.public
  r.assets

  r.on "webhook" do
    r.hash_branches(:webhook_prefix)
  end

  r.rodauth

  check_csrf!
  rodauth.load_memory
  rodauth.check_active_session

  r.root do
    r.redirect rodauth.login_route
  end
  rodauth.require_authentication

  r.hash_branches("")

Webhooks dispatch to a different set of routing trees,


  r.public
  r.assets

  r.on "webhook" do
    r.hash_branches(:webhook_prefix)
  end

  r.rodauth

  check_csrf!
  rodauth.load_memory
  rodauth.check_active_session

  r.root do
    r.redirect rodauth.login_route
  end
  rodauth.require_authentication

  r.hash_branches("")

as they do not need cross site request forgery checks, nor do they require the same authentication as logged in users. This type of setup is possible in other frameworks, but it's significantly simpler in Roda.


  r.public
  r.assets

  r.on "webhook" do
    r.hash_branches(:webhook_prefix)
  end

  r.rodauth

  check_csrf!
  rodauth.load_memory
  rodauth.check_active_session

  r.root do
    r.redirect rodauth.login_route
  end
  rodauth.require_authentication

  r.hash_branches("")

So that's how some production open source applications are using Roda to simplify their web development.

Open Source

using Roda

As we get near the end of the presentation, I'm happy to announce that after 10 years,

10 Years of Roda

Roda recently passed 10 million downloads! So if you haven't already tried using Roda, now is a great time to start.

10 Million

Downloads

If you are wondering about the future of Roda, I'm happy to announce

The Future of Roda

that I've joined Ubicloud, and part of my job is continuing to maintain Roda and other open source libraries on top of which Ubicloud is built.

@

I hope you had fun learning about the first 10 years of Roda.

10 Years of Roda

If you are looking at reducing your cloud spend, or want an easy way to deploy Ruby apps to the cloud with Kamal, stop by the Ubicloud booth and talk to us. We would love to work with you on it.

That concludes my presentation. I would like to thank all of you for listening to me.