What is Rack middleware?

http ruby ruby-on-rails web-applications rack

What is Rack middleware in Ruby? I couldn't find any good explanation for what they mean by "middleware".


Solution 1:

Rack as Design

Rack middleware is more than "a way to filter a request and response" - it's an implementation of the pipeline design pattern for web servers using Rack.

It very cleanly separates out the different stages of processing a request - separation of concerns being a key goal of all well designed software products.

For example with Rack I can have separate stages of the pipeline doing:

  • Authentication: when the request arrives, are the users logon details correct? How do I validate this OAuth, HTTP Basic Authentication, name/password?

  • Authorisation: "is the user authorised to perform this particular task?", i.e. role-based security.

  • Caching: have I processed this request already, can I return a cached result?

  • Decoration: how can I enhance the request to make downstream processing better?

  • Performance & Usage Monitoring: what stats can I get from the request and response?

  • Execution: actually handle the request and provide a response.

Being able to separate the different stages (and optionally include them) is a great help in developing well structured applications.

Community

There's also a great eco-system developing around Rack Middleware - you should be able to find pre-built rack components to do all of the steps above and more. See the Rack GitHub wiki for a list of middleware.

What's Middleware?

Middleware is a dreadful term which refers to any software component/library which assists with but is not directly involved in the execution of some task. Very common examples are logging, authentication and the other common, horizontal processing components. These tend to be the things that everyone needs across multiple applications but not too many people are interested (or should be) in building themselves.

More Information

  • The comment about it being a way to filter requests probably comes from the RailsCast episode 151: Rack Middleware screen cast.

  • Rack middleware evolved out of Rack and there is a great intro at Introduction to Rack middleware.

  • There's an intro to middleware on Wikipedia here.

Solution 2:

First of all, Rack is exactly two things:

  • A webserver interface convention
  • A gem

Rack - The Webserver Interface

The very basics of rack is a simple convention. Every rack compliant webserver will always call a call method on an object you give him and serve the result of that method. Rack specifies exactly how this call method has to look like, and what it has to return. That's rack.

Let's give it a simple try. I'll use WEBrick as rack compliant webserver, but any of them will do. Let's create a simple web application that returns a JSON string. For this we'll create a file called config.ru. The config.ru will automatically be called by the rack gem's command rackup which will simply run the contents of the config.ru in a rack-compliant webserver. So let's add the following to the config.ru file:

class JSONServer
  def call(env)
    [200, {"Content-Type" => "application/json"}, ['{ "message" : "Hello!" }']]
  end
end

map '/hello.json' do
  run JSONServer.new
end

As the convention specifies our server has a method called call that accepts an environment hash and returns an array with the form [status, headers, body] for the webserver to serve. Let's try it out by simply calling rackup. A default rack compliant server, maybe WEBrick or Mongrel will start and immediately wait for requests to serve.

$ rackup
[2012-02-19 22:39:26] INFO  WEBrick 1.3.1
[2012-02-19 22:39:26] INFO  ruby 1.9.3 (2012-01-17) [x86_64-darwin11.2.0]
[2012-02-19 22:39:26] INFO  WEBrick::HTTPServer#start: pid=16121 port=9292

Let's test our new JSON server by either curling or visiting the url http://localhost:9292/hello.json and voila:

$ curl http://localhost:9292/hello.json
{ message: "Hello!" }

It works. Great! That's the basis for every web framework, be it Rails or Sinatra. At some point they implement a call method, work through all the framework code, and finally return a response in the typical [status, headers, body] form.

In Ruby on Rails for example the rack requests hits the ActionDispatch::Routing.Mapper class which looks like this:

module ActionDispatch
  module Routing
    class Mapper
      ...
      def initialize(app, constraints, request)
        @app, @constraints, @request = app, constraints, request
      end

      def matches?(env)
        req = @request.new(env)
        ...
        return true
      end

      def call(env)
        matches?(env) ? @app.call(env) : [ 404, {'X-Cascade' => 'pass'}, [] ]
      end
      ...
  end
end

So basically Rails checks, dependent on the env hash if any route matches. If so it passes the env hash on to the application to compute the response, otherwise it immediately responds with a 404. So any webserver that is is compliant with the rack interface convention, is able to serve a fully blown Rails application.

Middleware

Rack also supports the creation of middleware layers. They basically intercept a request, do something with it and pass it on. This is very useful for versatile tasks.

Let's say we want to add logging to our JSON server that also measures how long a request takes. We can simply create a middleware logger that does exactly this:

class RackLogger
  def initialize(app)
    @app = app
  end

  def call(env)
    @start = Time.now
    @status, @headers, @body = @app.call(env)
    @duration = ((Time.now - @start).to_f * 1000).round(2)

    puts "#{env['REQUEST_METHOD']} #{env['REQUEST_PATH']} - Took: #{@duration} ms"
    [@status, @headers, @body]
  end
end

When it gets created, it saves itself a copy of the actual rack application. In our case that's an instance of our JSONServer. Rack automatically calls the call method on the middleware and expects back a [status, headers, body] array, just like our JSONServer returns.

So in this middleware, the start point is taken, then the actual call to the JSONServer is made with @app.call(env), then the logger outputs the logging entry and finally returns the response as [@status, @headers, @body].

To make our little rackup.ru use this middleware, add a use RackLogger to it like this:

class JSONServer
  def call(env)
    [200, {"Content-Type" => "application/json"}, ['{ "message" : "Hello!" }']]
  end
end

class RackLogger
  def initialize(app)
    @app = app
  end

  def call(env)
    @start = Time.now
    @status, @headers, @body = @app.call(env)
    @duration = ((Time.now - @start).to_f * 1000).round(2)

    puts "#{env['REQUEST_METHOD']} #{env['REQUEST_PATH']} - Took: #{@duration} ms"
    [@status, @headers, @body]
  end
end

use RackLogger

map '/hello.json' do
  run JSONServer.new
end

Restart the server and voila, it outputs a log on every request. Rack allows you to add multiple middlewares that are called in the order they are added. It's just a great way to add functionality without changing the core of the rack application.

Rack - The Gem

Although rack - first of all - is a convention it also is a gem that provides great functionality. One of them we already used for our JSON server, the rackup command. But there's more! The rack gem provides little applications for lots of use cases, like serving static files or even whole directories. Let's see how we serve a simple file, for example a very basic HTML file located at htmls/index.html:

<!DOCTYPE HTML>
  <html>
  <head>
    <title>The Index</title>
  </head>

  <body>
    <p>Index Page</p>
  </body>
</html>

We maybe want to serve this file from the website root, so let's add the following to our config.ru:

map '/' do
  run Rack::File.new "htmls/index.html"
end

If we visit http://localhost:9292 we see our html file perfectly rendered. That's was easy, right?

Let's add a whole directory of javascript files by creating some javascript files under /javascripts and adding the following to the config.ru:

map '/javascripts' do
  run Rack::Directory.new "javascripts"
end

Restart the server and visit http://localhost:9292/javascript and you'll see a list of all javascript files you can include now straight from anywhere.

Solution 3:

I had a problem understanding Rack myself for a good amount of time. I only fully understood it after working on making this miniature Ruby web server myself. I've shared my learnings about Rack (in the form of a story) here on my blog: http://blog.gauravchande.com/what-is-rack-in-ruby-rails

Feedback is more than welcome.

Solution 4:

What is Rack?

Rack provides a minimal interface between between webservers supporting Ruby and Ruby frameworks.

Using Rack you can write a Rack Application.

Rack will pass the Environment hash (a Hash, contained inside a HTTP request from a client, consisting of CGI-like headers) to your Rack Application which can use things contained in this hash to do whatever it wants.

What is a Rack Application?

To use Rack, you must provide an 'app' - an object that responds to the #call method with the Environment Hash as a parameter (typically defined as env). #call must return an Array of exactly three values:

  • the Status Code (eg '200'),
  • a Hash of Headers,
  • the Response Body (which must respond to the Ruby method, each).

You can write a Rack Application that returns such an array - this will be sent back to your client, by Rack, inside a Response (this will actually be an instance of the Class Rack::Response [click to go to docs]).

A Very Simple Rack Application:

  • gem install rack
  • Create a config.ru file - Rack knows to look for this.

We will create a tiny Rack Application that returns a Response (an instance of Rack::Response) who's Response Body is an array that contains a String: "Hello, World!".

We will fire up a local server using the command rackup.

When visiting the relevant port in our browser we will see "Hello, World!" rendered in the viewport.

#./message_app.rb
class MessageApp
  def call(env)
    [200, {}, ['Hello, World!']]
  end
end

#./config.ru
require_relative './message_app'

run MessageApp.new

Fire up a local server with rackup and visit localhost:9292 and you should see 'Hello, World!' rendered.

This is not a comprehensive explanation, but essentially what happens here is that the Client (the browser) sends a HTTP Request to Rack, via your local server, and Rack instantiates MessageApp and runs call, passing in the Environment Hash as a parameter into the method (the env argument).

Rack takes the return value (the array) and uses it to create an instance of Rack::Response and sends that back to the Client. The browser uses magic to print 'Hello, World!' to the screen.

Incidentally, if you want to see what the environment hash looks like, just put puts env underneath def call(env).

Minimal as it is, what you have written here is a Rack application!

Making a Rack Application interact with the Incoming Environment hash

In our little Rack app, we can interact with the env hash (see here for more about the Environment hash).

We will implement the ability for the user to input their own query string into the URL, hence, that string will be present in the HTTP request, encapsulated as a value in one of the key/value pairs of the Environment hash.

Our Rack app will access that query string from the Environment hash and send that back to the client (our browser, in this case) via the Body in the Response.

From the Rack docs on the Environment Hash: "QUERY_STRING: The portion of the request URL that follows the ?, if any. May be empty, but is always required!"

#./message_app.rb
class MessageApp
  def call(env)
    message = env['QUERY_STRING']
    [200, {}, [message]]
  end
end

Now, rackup and visit localhost:9292?hello (?hello being the query string) and you should see 'hello' rendered in the viewport.

Rack Middleware

We will:

  • insert a piece of Rack Middleware into our codebase - a class: MessageSetter,
  • the Environment hash will hit this class first and will be passed in as a parameter: env,
  • MessageSetter will insert a 'MESSAGE' key into the env hash, its value being 'Hello, World!' if env['QUERY_STRING'] is empty; env['QUERY_STRING'] if not,
  • finally, it will return @app.call(env) - @app being the next app in the 'Stack': MessageApp.

First, the 'long-hand' version:

#./middleware/message_setter.rb
class MessageSetter
  def initialize(app)
    @app = app
  end

  def call(env)
    if env['QUERY_STRING'].empty?
      env['MESSAGE'] = 'Hello, World!'
    else
      env['MESSAGE'] = env['QUERY_STRING']
    end
    @app.call(env)
  end
end

#./message_app.rb (same as before)
class MessageApp
  def call(env)
    message = env['QUERY_STRING']
    [200, {}, [message]]
  end
end

#config.ru
require_relative './message_app'
require_relative './middleware/message_setter'

app = Rack::Builder.new do
  use MessageSetter
  run MessageApp.new
end

run app

From the Rack::Builder docs we see that Rack::Builder implements a small DSL to iteratively construct Rack applications. This basically means that you can build a 'Stack' consisting of one or more Middlewares and a 'bottom level' application to dispatch to. All requests going through to your bottom-level application will be first processed by your Middleware(s).

#use specifies middleware to use in a stack. It takes the middleware as an argument.

Rack Middleware must:

  • have a constructor that takes the next application in the stack as a parameter.
  • respond to the call method that takes the Environment hash as a parameter.

In our case, the 'Middleware' is MessageSetter, the 'constructor' is MessageSetter's initialize method, the 'next application' in the stack is MessageApp.

So here, because of what Rack::Builder does under the hood, the app argument of MessageSetter's initialize method is MessageApp.

(get your head around the above before moving on)

Therefore, each piece of Middleware essentially 'passes down' the existing Environment hash to the next application in the chain - so you have the opportunity to mutate that environment hash within the Middleware before passing it on to the next application in the stack.

#run takes an argument that is an object that responds to #call and returns a Rack Response (an instance of Rack::Response).

Conclusions

Using Rack::Builder you can construct chains of Middlewares and any request to your application will be processed by each Middleware in turn before finally being processed by the final piece in the stack (in our case, MessageApp). This is extremely useful because it separates-out different stages of processing requests. In terms of 'separation of concerns', it couldn't be much cleaner!

You can construct a 'request pipeline' consisting of several Middlewares that deal with things such as:

  • Authentication
  • Authorisation
  • Caching
  • Decoration
  • Performance & Usage Monitoring
  • Execution (actually handle the request and provide a response)

(above bullet points from another answer on this thread)

You will often see this in professional Sinatra applications. Sinatra uses Rack! See here for the definition of what Sinatra IS!

As a final note, our config.ru can be written in a short-hand style, producing exactly the same functionality (and this is what you'll typically see):

require_relative './message_app'
require_relative './middleware/message_setter'

use MessageSetter
run MessageApp.new

And to show more explicitly what MessageApp is doing, here is its 'long-hand' version that explicitly shows that #call is creating a new instance of Rack::Response, with the required three arguments.

class MessageApp
  def call(env)
    Rack::Response.new([env['MESSAGE']], 200, {})
  end
end

Useful links

  • Complete code for this post (Github repo commit)
  • Good Blog Post, "Introduction to Rack Middleware"
  • Some good Rack documentation

Solution 5:

config.ru minimal runnable example

app = Proc.new do |env|
  [
    200,
    {
      'Content-Type' => 'text/plain'
    },
    ["main\n"]
  ]
end

class Middleware
  def initialize(app)
    @app = app
  end

  def call(env)
    @status, @headers, @body = @app.call(env)
    [@status, @headers, @body << "Middleware\n"]
  end
end

use(Middleware)

run(app)

Run rackup and visit localhost:9292. The output is:

main
Middleware

So it is clear that the Middleware wraps and calls the main app. Therefore it is able to pre-process the request, and post-process the response in any way.

As explained at: http://guides.rubyonrails.org/rails_on_rack.html#action-dispatcher-middleware-stack , Rails uses Rack middlewares for a lot of it's functionality, and you can add you own too with config.middleware.use family methods.

The advantage of implementing functionality in a middleware is that you can reuse it on any Rack framework, thus all major Ruby ones, and not just Rails.

Related

How to view or edit localStorage
What is the difference between required and ng-required?
JSON and XML comparison [closed]
How long is the SHA256 hash?
Constructor initialization-list evaluation order
How to prevent a jQuery Ajax request from caching in Internet Explorer?
Match all elements having class name starting with a specific string [duplicate]
What does $ mean before a string?
What is the bower (and npm) version syntax?
How to center an iframe horizontally?
serialize/deserialize java 8 java.time with Jackson JSON mapper
Which Architecture patterns are used on Android? [closed]