As Ruby developers, we are familiar with popular web frameworks such as Rails, Sinatra and Hanami. These frameworks make our lives much easier due to the built-in features, conventions that allow others to easily understand our code, and the use of the vast Ruby ecosystem.

Knowledge of these frameworks enable developers to create feature-rich web applications in a short amount of time. But do you know the layer beneath that framework? Are you aware that these frameworks use a mini-framework within? As part of the series on Web Application Basics, we will introduce Rack and why it is important for developers to know how it works.

What is Rack?

Rack is a Ruby library that serves as a Web Server interface. It provides a standard way for a Ruby application to communicate with a Web/Application Server. In the previous article we introduced some Application Servers for Ruby such as Webrick, Unicorn, and Puma.

A standard interface is essential as this makes it easy for applications to use different Application Servers. For example, in a Rails application we can use Webrick for development but use Puma in production. Rack makes sure that the application still works on these different server configurations.

Ruby applications that follow the Rack interface are called Rack applications or Rack apps. Frameworks such as Rails, Sinatra, Hanami, and Roda are all examples of Rack apps. This means that they can be seamlessly plugged in to different Application Servers, and as we can see later, Rack apps can also be used together like building blocks to enhance web applications.

Rack Apps

To conform to the Rack interface or API, the code must have a predefined input and output:

• It implements a call method
• The input parameter must be a hash, which is the request data
• It returns an output as an array
• The output array must contain the status code, headers, and the body
• The body must respond to each, e.g. Enumerable

To illustrate this, the code below shows a simple Ruby class that conforms to the above, and is therefore a valid Rack application.

class Application
  def call(env)
    status = 200
    headers = { "Content-Type" => "text/html" }
    body = ["Hello world!"]

    [status, headers, body]
  end
end

run Application.new

The code may not look like much, but this is already a web application that can be loaded into a browser. How can we do that?

Rackup

Rack comes with its built-in executable called rackup. This is a program that looks for the default Rack configuration file (config.ru) and then starts an Application Server called Webrick. It uses port 9292 by default, which can be accessed using a browser.

Webrick is a small and simple Ruby Application Server that is a part of the Ruby standard library. While it is not built for production systems, it is more than enough for development or for small, internal web applications.

To illustrate, create a file called config.ru in a directory with the following contents (same as the example above):

class Application
  def call(env)
    status = 200
    headers = { "Content-Type" => "text/html" }
    body = ["Hello world!"]

    [status, headers, body]
  end
end

run Application.new

Then run this with the rackup command:

> rackup

This command will look for the config.ru file we just created, then runs Webrick on port 9292. We can now view the web application in the browser!

However, this does not look like a web application at all. Instead of just displaying text in the browser, the body component of the response can also be an HTML string, or even an HTML file:

body = [File.read('index.html')]

So the Rack app now looks like this:

class Application
def call(env)
status = 200
headers = { "Content-Type" => "text/html" }
body = [File.read('index.html')]

[status, headers, body]
end
end

run Application.new read more

Once a web request traveled through the Internet and reached the server, it can now be processed, right? Not so fast! In a production setup, the request does not reach the application right away. We will introduce the different services that support a web application: Content Delivery Networks, Load Balancers, Reverse Proxies, Web Servers, and Application Servers.

Why do we need all of this?

Technically, it is possible to connect an application directly to the Internet and start serving requests. While this will suffice for a small Internet-of-Things home service, this is going to be problematic in a real-world production use. read more