Simple Web Applications using Rack

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

Web Development Basics: Server

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

Web Development Basics: Security

In the previous article we discussed how requests through the Internet are protected using HTTPS. This is made possible through the use of TLS Certificates. In this article we will discuss what these certificates are, the different types, and how anyone can use them for their own web application.

TLS certificates

To establish a secure communication between a browser and the server, the first step is to do what is called a TLS handshake. In this process, the public key of the server is used to generate the key that is used for symmetric encryption. This public key is shared using a TLS certificate. read more

Web Development Basics: Transit

In the previous article we discussed how a user sends a request to a server by using URLs in a browser. Now we will explore what happens to that request once it leaves the user’s computer, how it travels through the Internet, and how it is protected.

Internet

Together with advances in transportation, the Internet made the world a much smaller place. As long as there is an Internet connection, your content or product can be accessed and purchased by anyone, anywhere.

Technically, the Internet is a network of networks communicating via TCP/IP. Networks located within a country are then connected to other countries through the use of submarine cables. These cables, laid deep in the ocean, carry Terabytes of information per second. read more

Web Development Basics: User

As software developers making web applications, most of the time we are engrossed in our own code. Designing features, thinking of the best ways to build it, and fixing bugs are what we do most of the time. We often treat our application as a black box, a standalone unit that accepts requests and spits out JSON or HTML. However, this is a shortsighted way of doing web development.

In this series we will explore the realm beyond the application that we are building. We will think of this as the journey of a web request starting from the user’s Web Browser (User), as it traverses through the Internet (Transit), and finally when it reaches the backend (Server). read more