Scalable Web Framework aimed at Speed and Simplicity
Switch branches/tags
Nothing to show
Pull request Compare This branch is 30 commits ahead of widler:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Scalable Web Framework aimed at Speed and Simplicity

Quick Start


$ [sudo] gem install e


require 'e'

class App < E

  map '/'

  def index
    # ...


Espresso in the wild?

Yes, CIBox service is built entirely on Espresso Framework.

Source Code



Actions | Controllers | Slices | MVC?


Base URL | Canonicals | Actions | Actions Mapping | Parametrization | Format | RESTful Actions | Aliases | Rewriter


Global Setup | Setup by Name | Setup by Format | Remote Setup


Route | Params | Passing Control | Fetching Body | Halt | Redirect | Reload | Streaming | Error Handlers | Hooks | Authorization | Sessions | Flash | Cookies | Content Type | Charset | Cache Control | Expires | Last Modified | Accepted Content Type | Cache Manager | Send File | Send Files | Attachment | Headers

View API

Engine | Extension | Templates Path | Layouts Path | Layout
Rendering Templates | Rendering Layouts | Ad hoc Rendering | Templates Compilation


Intro | Mapper | Server | Helpers | Loader


Intro | Resource | Excluded Params | Root | Response | Access Restriction


Controllers | Slices | Roots | Run |

Highlights / Motivation


In terms of performance, the only really important thing for any framework it is to add as low overhead as possible.

The overhead are the time consumed by framework to accept the request then prepare and send response.

The tests that follows will allow to disclose the overhead added by various frameworks.

The overhead are calculated by dividing 1000 milliseconds to framework’s standard speed.

The framework’s standard speed are the speed of HelloWorld app running on top of given framework.

The framework’s standard speed means nothing by itself. It is only used to calculate the framework’s overhead.

Tested apps will run on Thin web server and will return a trivial "Hello World!" response.

Hardware used:

Processor Name: Intel Core i5
Processor Speed: 3.31 GHz
Number of Processors: 1
Total Number of Cores: 4
Memory: 8 GB

To run tests on your hardware, clone Espresso Framework repository and execute rake overhead inside it.

Test results:

            Speed  Overhead  1ms-app  5ms-app  10ms-app  20ms-app  50ms-app  100ms-app
  espresso  5518   0.18ms    847      193      98        49        19        9
   sinatra  3629   0.28ms    783      189      97        49        19        9
     rails  792    1.26ms    442      159      88        47        19        9

1ms-app shows your app speed when your actions takes 1ms to run.
10ms-app shows your app speed when your actions takes 10ms to run.

The app speed are calculated as follow:

1000 / (time taken by action + time taken by framework)

So, if your actions takes about 1ms and you use a framework with overhead of 0.18ms, the app speed will be:

1000 / ( 1 + 0.18 ) = 847 requests per second

However, if framework's overhead is of 1ms or more, the app speed will decrease dramatically:

1000 / ( 1 + 1.26 ) = 442 requests per second


The framework speed matter only if your code matter.

If you develop a site aimed to serve a serious amount of requests, you should write actions that takes insignificant amount of time.

Only after that it make sense to think about framework speed.

Worth to Note - Espresso has built-in cache manager as well as views compiler.

These tools may help you to dramatically reduce the time consumed by your actions.

Natural Action/Routes/Params

I never understood why should i create actions in some file, then open another file and directing requests to created action.
Even worse! To use params inside action, i have to remember how i named them in another file. And when i want to change a param name i have to change it in both files?

What about consistency?

A good tradeoff would be to use some DSL.

get '/book/:id' do

Looks much better.

But! Strings/Regexps as action names? No, thanks.

What if i need to remount a bunch of actions to a new root? Say from /news to /headlines? Refactoring? Using vars/constants in names? No, Thanks.

How do i setup multiple actions?
How do i find out the currently running action?

What if i do a request like "/book/100/?id=200"? What? Should i use unique param names? No, thanks.

etc. etc.

And why should i remember so many non-natural stuff?

Is not Ruby powerfull enough? I guess it is:

def book id


That's a regular Ruby method and a regular Espresso action.
That's also an Espresso route. Yes, the app will respond to "/book/100"
And of course action params are used naturally, through method arguments(id rather than params[:id]).

And all this offered by Ruby for free! Why to reinvent the wheel?

Expressive Setup

Usually you do not want to instruct each action about how it should behave.

It would take eras to define inside each action what content type should it return or what layout should it render.

Instead, you will use few lines of code at class level to write instructions that will be followed by all actions.

Example: Instruct all actions under App controller to return JSON Content-Type

class App < E
    content_type :json
    # ...

But what if you need to setup only specific actions?

Simple! Put your setup, well, inside setup block and pass action names as parameters.

Example: Instruct only rss and feed actions to return XML Content-Type

class App < E

    setup :rss, :feed do
        content_type :xml
    # ...

Well, what if i need some setup for some 10 actions ad another setup for another 20 actions? Should i pass 30 arguments to setup? I do not want to buy a new keyboard every month...

That's simple too. Use regular expressions.

Ex: setup only news related actions:

class App < E

    setup /news/ do
        # some setup
    # ...


Portability and DRY done right and easy.

With Espresso, any controller can be mounted under any app.

Even more, any set of controllers - a.k.a. slices - can be mounted under any app.

To create a slice simply put your controllers under some module.

Then you can mount that module under any Espresso app.

Even more, when mounting you can easily setup all controllers(or some) at once.

And of course when mounting, you can give a mount point.

module Cms

    class Articles < E
        # ...

    class News < E
        # ...

    class Pages < E
        # ...

app = Cms.mount do
    # some setup that will run inside each controller

# or
app = Cms.mount do |ctrl|
    # some setup that will run inside controllers that match `ctrl` param

RESTful Actions

By default, verbless actions will respond to any request type.

To make some action to respond only to some request type, simply prepend the corresponding verb to the action name.

# will respond to any request type
def book
    # ...

def get_book
    # ...

def post_book
    # ...

def put_book
    # ...

# etc.

Flexible Rewriter

With Espresso built-in rewriter you can redirect any requests to new URL.

However, beside trivial redirects, rewriter can also pass the control to an arbitrary controller#action or simply halt the request and send the response.

Views Compiler

For most web sites, most time are spent at templates rendering.
When rendering templates, most time are spent at reading and compiling.

Espresso allow to easily skip these expensive operations by keeping compiled templates in memory and just render them on consequent requests.


If you have some expensive operations that basically return static data, simply put them inside cache block.

The result will be cached and returned on consequent requests.

To clear cache, simply call clear_cache!