I love Ruby. I also love object-oriented programming. However, nowadays functional programming is getting more and more attention. And that’s not surprising because the functional paradigm has a lot of advantages.

Ruby, being a multi-paradigm language, allows us to write programs in a functional style. Let’s see if we can write a web application this way. Maybe we even end up inventing a web framework ;)

Ground rules

Let’s establish some ground rules.

Lambdas. Lambdas everywhere Arrays. We can use arrays and some methods from Enumerable like map, reduce, find, select, reject Hashes. We can access values via [key] and use merge for modifying them (no mutations!) Keeping external dependencies (like rack utility functions) to a minimum.

Rack

Rack provides a minimal, modular, and adaptable interface for developing web applications in Ruby.

Rack is used by Rails and Sinatra. You can learn more about it here: https://github.com/rack/rack

Rack expects an application to be an object with a call method accepting env (hash containing all the information about a request) and returning a 3-element tuple:

[status_code, headers_hash, body_array]

(body array is usually a list of strings)

This is great because it uses basic data structures and the call method indicates that we can use a lambda/proc as an application.

Setup

Let’s set up an app first.

Gemfile

Generate a Gemfile with bundle init and add Rack to it.

config.ru

config.ru is a script being run by rackup program shipping with Rack and starting a webserver.

Rack reloader will reload our application without restarting the server.

We will also assume that our app source code will define the APP constant with our app lambda. We also need to wrap it into another lambda or Rack won’t pick up changes to the constant.

app.rb

Now we can start the webserver with bundle exec rackup . It should be available on http://localhost:9292

Routing

Let’s add a route for /hello showing “Hello world” message. Also, a 404 page.

Handlers

Let’s move our previous lambda from APP to a handler variable.

Routes

Let’s define routes as a list of pairs condition + handler:

We could also make a data type out of routes. For that, instead of explicitly writing them as pairs we should create a function route(matcher, handler) and getter functions route_matcher(route) and route_handler(route) . This way the code becomes more flexible since it won’t know a lot about the data structure implementation. However, let’s keep it simple.

Router

A router is a dispatch function that decides which handler to use for a request.

Middleware

Let’s make users provide their name to greet them properly.

For that, we need a params hash.

Params middleware

A middleware is just a wrapper over a handler that modifies the env or the result returned from it.

Let’s create a middleware that adds params hash to env before handing it over to a handler.

The handler

Let’s use the new parameter in a handler.

Now we should be able to see a greeting here:

http://localhost:9292/hello?name=John+Doe

Content-Type header

Let’s also add text/html content-type header.

Listing middleware

Right now we are adding a middleware by directly calling it on a handler.

It would look nicer if we could just list them and apply later.

The identity function is great. Composing it with another function has zero effect so it’s great as an init value for reducing.

Conclusion?

We have implemented a small web application. It doesn’t do much though. However, it’s interesting how far we could go by just using lambdas, arrays, and hashes.

Database interactions would introduce side-effects to our code. As an idea, they could be put into methods so it’s easier to distinguish them from pure lambdas.

We could also make a framework from it by moving the essential stuff to hashes and assigning them to constants. For example,

You can find the complete source code here.