rack

A modular Ruby web server interface.

5,017

1,654

5,017

View on GitHub

Top Related Projects

sinatra

12,335

Classy web-development dressed in a DSL (official / canonical repo)

express

67,245

Fast, unopinionated, minimalist web framework for node.

django

84,447

The Web framework for perfectionists with deadlines.

fastify

34,045

Fast and low overhead web framework, for Node.js

Quick Overview

Rack is a modular Ruby web server interface that provides a minimal, adaptable API for developing web applications. It serves as a middleware layer between web servers and Ruby web frameworks, allowing for easy integration and flexibility in web application development.

Pros

Simplifies web application development by providing a consistent interface between web servers and Ruby frameworks
Highly modular and extensible, allowing developers to easily add or modify functionality
Widely adopted and supported by major Ruby web frameworks like Rails and Sinatra
Lightweight and performant, with minimal overhead

Cons

Can be complex for beginners to understand and implement effectively
Documentation can be sparse or outdated for some advanced features
May require additional configuration for optimal performance in production environments
Limited built-in security features, requiring developers to implement their own security measures

Code Examples

Basic Rack application:

# config.ru
run lambda { |env|
  [200, {'Content-Type' => 'text/plain'}, ['Hello, World!']]
}

This example creates a simple Rack application that returns "Hello, World!" with a 200 status code.

Using Rack::Builder to create a middleware stack:

# config.ru
require 'rack'

app = Rack::Builder.new do
  use Rack::CommonLogger
  use Rack::ShowExceptions
  run lambda { |env| [200, {'Content-Type' => 'text/plain'}, ['Hello from Rack!']] }
end

run app

This example demonstrates how to use Rack::Builder to create a middleware stack with logging and exception handling.

Creating a custom Rack middleware:

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

  def call(env)
    status, headers, body = @app.call(env)
    headers['X-Custom-Header'] = 'Hello from middleware'
    [status, headers, body]
  end
end

use CustomMiddleware
run MyApp

This example shows how to create a custom Rack middleware that adds a custom header to the response.

Getting Started

To get started with Rack, follow these steps:

Install Rack:
```
gem install rack
```

Create a config.ru file with your Rack application:

# config.ru
run lambda { |env|
  [200, {'Content-Type' => 'text/plain'}, ['Hello, Rack!']]
}

Run the Rack application:
```
rackup config.ru
```
Visit http://localhost:9292 in your browser to see your Rack application in action.

Competitor Comparisons

sinatra

12,335

Classy web-development dressed in a DSL (official / canonical repo)

Pros of Sinatra

Higher-level abstraction, making it easier to build web applications quickly
Built-in routing and templating support
More user-friendly DSL for defining routes and handlers

Cons of Sinatra

Less flexible than Rack for low-level HTTP handling
Slightly higher overhead due to additional abstractions
May be overkill for very simple applications or microservices

Code Comparison

Rack example:

app = Proc.new do |env|
  ['200', {'Content-Type' => 'text/html'}, ['Hello World']]
end

Sinatra example:

require 'sinatra'

get '/' do
  'Hello World'
end

Summary

Rack provides a minimal interface between web servers and Ruby applications, offering great flexibility and low-level control. Sinatra, built on top of Rack, provides a more intuitive and higher-level framework for building web applications. While Rack excels in simplicity and performance for basic tasks, Sinatra offers a more developer-friendly experience with built-in routing and templating. The choice between the two depends on the specific requirements of your project, with Rack being ideal for low-level control and Sinatra for rapid development of small to medium-sized web applications.

rails

57,226

Ruby on Rails

Pros of Rails

Full-featured web application framework with built-in ORM, routing, and MVC architecture
Extensive ecosystem with gems and plugins for various functionalities
Convention over configuration approach, leading to faster development

Cons of Rails

Steeper learning curve due to its comprehensive nature
Can be overkill for simple applications or microservices
Slower performance compared to lightweight alternatives

Code Comparison

Rack (basic application):

app = lambda do |env|
  [200, {'Content-Type' => 'text/plain'}, ['Hello, World!']]
end
run app

Rails (basic controller action):

class WelcomeController < ApplicationController
  def index
    render plain: 'Hello, World!'
  end
end

Summary

Rails is a comprehensive web application framework built on top of Rack, offering a full suite of tools and conventions for rapid development. Rack, on the other hand, is a minimal interface between web servers and Ruby applications, providing a foundation for other frameworks like Rails.

While Rails excels in building complex, feature-rich applications quickly, Rack offers more flexibility and lightweight performance for simpler projects or microservices. The choice between the two depends on the project's requirements, scale, and the developer's familiarity with Ruby ecosystem.

express

67,245

Fast, unopinionated, minimalist web framework for node.

Pros of Express

More comprehensive framework with built-in routing and middleware support
Larger ecosystem with extensive third-party middleware and plugins
Better suited for building full-fledged web applications

Cons of Express

Heavier and more opinionated than Rack's minimalist approach
Steeper learning curve for beginners due to more features and complexity
Less flexibility in terms of server implementation choices

Code Comparison

Rack:

app = Proc.new do |env|
  ['200', {'Content-Type' => 'text/html'}, ['Hello World']]
end

Express:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello World');
});

Both examples show a simple "Hello World" response, but Express provides a more intuitive API for routing and handling requests. Rack's approach is more low-level, giving developers more control over the request-response cycle at the cost of verbosity.

While Rack offers a minimalist foundation for building web applications in Ruby, Express provides a more feature-rich framework for Node.js developers. The choice between them often depends on the specific project requirements and the developer's preferred language ecosystem.

django

84,447

The Web framework for perfectionists with deadlines.

Pros of Django

Full-featured web framework with built-in ORM, admin interface, and authentication system
Extensive documentation and large, active community support
Follows the "batteries included" philosophy, providing many out-of-the-box features

Cons of Django

Steeper learning curve due to its comprehensive nature
Can be overkill for small, simple projects
Less flexibility in choosing components compared to Rack's minimalist approach

Code Comparison

Django (URL routing):

urlpatterns = [
    path('admin/', admin.site.urls),
    path('blog/', include('blog.urls')),
    path('', views.home, name='home'),
]

Rack (basic application):

app = Rack::Builder.new do
  map "/" do
    run Proc.new { |env| [200, {"Content-Type" => "text/html"}, ["Hello World!"]] }
  end
end

Django provides a more structured approach to URL routing, while Rack offers a minimalist foundation for building web applications. Django's code is more declarative, whereas Rack's is more functional and flexible.

spring-framework

58,577

Spring Framework

Pros of Spring Framework

More comprehensive, offering a full-stack application framework
Extensive documentation and large community support
Powerful dependency injection and aspect-oriented programming features

Cons of Spring Framework

Steeper learning curve due to its complexity
Heavier footprint and potentially slower startup times
More configuration required for simple applications

Code Comparison

Spring Framework:

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "Hello, World!";
    }
}

Rack:

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello, World!"]]
  end
end

Spring Framework is a comprehensive Java-based framework for building enterprise applications, while Rack is a minimal Ruby web server interface. Spring offers a wide range of features and integrations, making it suitable for complex, large-scale projects. Rack, on the other hand, provides a simple and flexible foundation for building web applications in Ruby.

Spring's extensive ecosystem and robust tooling make it a popular choice for Java developers, but it can be overwhelming for beginners. Rack's simplicity allows for quick setup and easy understanding, making it ideal for smaller projects or as a building block for other frameworks like Ruby on Rails.

fastify

34,045

Fast and low overhead web framework, for Node.js

Pros of Fastify

Significantly faster performance due to its optimized architecture
Built-in support for JSON Schema validation
Extensive plugin ecosystem for easy extensibility

Cons of Fastify

Steeper learning curve for developers new to the framework
Smaller community compared to more established frameworks
Less suitable for simple, lightweight applications

Code Comparison

Rack:

run lambda { |env|
  [200, {'Content-Type' => 'text/plain'}, ['Hello, World!']]
}

Fastify:

fastify.get('/', async (request, reply) => {
  return { hello: 'world' }
})

Key Differences

Fastify is designed for high performance and low overhead, while Rack focuses on simplicity and compatibility
Fastify provides a more opinionated structure, whereas Rack offers a minimal interface for building web applications
Fastify is JavaScript-based, while Rack is primarily used with Ruby

Use Cases

Fastify: Ideal for building high-performance APIs and microservices
Rack: Well-suited for creating lightweight web applications and middleware in the Ruby ecosystem

Community and Ecosystem

Fastify has a growing community with active development and frequent updates
Rack has a mature ecosystem with widespread adoption in the Ruby community

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Rack provides a minimal, modular, and adaptable interface for developing web applications in Ruby. By wrapping HTTP requests and responses in the simplest way possible, it unifies and distills the bridge between web servers, web frameworks, and web application into a single method call.

The exact details of this are described in the Rack Specification, which all Rack applications should conform to. Browse the Documentation for more information.

Version support

Version	Support
3.1.x	Bug fixes and security patches.
3.0.x	Security patches only.
2.2.x	Security patches only.
<= 2.1.x	End of support.

Please see the Security Policy for more information.

Rack 3.1

This is the latest version of Rack. It contains bug fixes and security patches. Please check the Change Log for detailed information on specific changes.

Rack 3.0

This version of rack contains significant changes which are detailed in the Upgrade Guide. It is recommended to upgrade to Rack 3 as soon as possible to receive the latest features and security patches.

Rack 2.2

This version of Rack is receiving security patches only, and effort should be made to move to Rack 3.

Starting in Ruby 3.4 the base64 dependency will no longer be a default gem, and may cause a warning or error about base64 being missing. To correct this, add base64 as a dependency to your project.

Installation

Add the rack gem to your application bundle, or follow the instructions provided by a supported web framework:

# Install it generally:
$ gem install rack

# or, add it to your current application gemfile:
$ bundle add rack

If you need features from Rack::Session or bin/rackup please add those gems separately.

$ gem install rack-session rackup

Usage

Create a file called config.ru with the following contents:

run do |env|
  [200, {}, ["Hello World"]]
end

Run this using the rackup gem or another supported web server.

$ gem install rackup
$ rackup

# In another shell:
$ curl http://localhost:9292
Hello World

Supported web servers

Rack is supported by a wide range of servers, including:

Agoo
Falcon
Iodine
NGINX Unit
Phusion Passenger (which is mod_rack for Apache and for nginx)
Pitchfork
Puma
Thin
Unicorn
uWSGI
Lamby (for AWS Lambda)

You will need to consult the server documentation to find out what features and limitations they may have. In general, any valid Rack app will run the same on all these servers, without changing anything.

Rackup

Rack provides a separate gem, rackup which is a generic interface for running a Rack application on supported servers, which include WEBRick, Puma, Falcon and others.

Supported web frameworks

These frameworks and many others support the Rack Specification:

Available middleware shipped with Rack

Between the server and the framework, Rack can be customized to your applications needs using middleware. Rack itself ships with the following middleware:

Rack::CommonLogger for creating Apache-style logfiles.
Rack::ConditionalGet for returning Not Modified responses when the response has not changed.
Rack::Config for modifying the environment before processing the request.
Rack::ContentLength for setting a content-length header based on body size.
Rack::ContentType for setting a default content-type header for responses.
Rack::Deflater for compressing responses with gzip.
Rack::ETag for setting etag header on bodies that can be buffered.
Rack::Events for providing easy hooks when a request is received and when the response is sent.
Rack::Head for returning an empty body for HEAD requests.
Rack::Lint for checking conformance to the Rack Specification.
Rack::Lock for serializing requests using a mutex.
Rack::MethodOverride for modifying the request method based on a submitted parameter.
Rack::Recursive for including data from other paths in the application, and for performing internal redirects.
Rack::Reloader for reloading files if they have been modified.
Rack::Runtime for including a response header with the time taken to process the request.
Rack::Sendfile for working with web servers that can use optimized file serving for file system paths.
Rack::ShowException for catching unhandled exceptions and presenting them in a nice and helpful way with clickable backtrace.
Rack::ShowStatus for using nice error pages for empty client error responses.
Rack::Static for configurable serving of static files.
Rack::TempfileReaper for removing temporary files creating during a request.

All these components use the same interface, which is described in detail in the Rack Specification. These optional components can be used in any way you wish.

Convenience interfaces

If you want to develop outside of existing frameworks, implement your own ones, or develop middleware, Rack provides many helpers to create Rack applications quickly and without doing the same web stuff all over:

Rack::Request which also provides query string parsing and multipart handling.
Rack::Response for convenient generation of HTTP replies and cookie handling.
Rack::MockRequest and Rack::MockResponse for efficient and quick testing of Rack application without real HTTP round-trips.
Rack::Cascade for trying additional Rack applications if an application returns a not found or method not supported response.
Rack::Directory for serving files under a given directory, with directory indexes.
Rack::Files for serving files under a given directory, without directory indexes.
Rack::MediaType for parsing content-type headers.
Rack::Mime for determining content-type based on file extension.
Rack::RewindableInput for making any IO object rewindable, using a temporary file buffer.
Rack::URLMap to route to multiple applications inside the same process.

Configuration

Rack exposes several configuration parameters to control various features of the implementation.

`RACK_QUERY_PARSER_BYTESIZE_LIMIT`

This environment variable sets the default for the maximum query string bytesize that Rack::QueryParser will attempt to parse. Attempts to use a query string that exceeds this number of bytes will result in a Rack::QueryParser::QueryLimitError exception. If this enviroment variable is provided, it must be an integer, or Rack::QueryParser will raise an exception.

The default limit can be overridden on a per-Rack::QueryParser basis using the bytesize_limit keyword argument when creating the Rack::QueryParser.

`RACK_QUERY_PARSER_PARAMS_LIMIT`

This environment variable sets the default for the maximum number of query parameters that Rack::QueryParser will attempt to parse. Attempts to use a query string with more than this many query parameters will result in a Rack::QueryParser::QueryLimitError exception. If this enviroment variable is provided, it must be an integer, or Rack::QueryParser will raise an exception.

The default limit can be overridden on a per-Rack::QueryParser basis using the params_limit keyword argument when creating the Rack::QueryParser.

This is implemented by counting the number of parameter separators in the query string, before attempting parsing, so if the same parameter key is used multiple times in the query, each counts as a separate parameter for this check.

`param_depth_limit`

Rack::Utils.param_depth_limit = 32 # default

The maximum amount of nesting allowed in parameters. For example, if set to 3, this query string would be allowed:

?a[b][c]=d

but this query string would not be allowed:

?a[b][c][d]=e

Limiting the depth prevents a possible stack overflow when parsing parameters.

`multipart_file_limit`

Rack::Utils.multipart_file_limit = 128 # default

The maximum number of parts with a filename a request can contain. Accepting too many parts can lead to the server running out of file handles.

The default is 128, which means that a single request can't upload more than 128 files at once. Set to 0 for no limit.

Can also be set via the RACK_MULTIPART_FILE_LIMIT environment variable.

(This is also aliased as multipart_part_limit and RACK_MULTIPART_PART_LIMIT for compatibility)

`multipart_total_part_limit`

The maximum total number of parts a request can contain of any type, including both file and non-file form fields.

The default is 4096, which means that a single request can't contain more than 4096 parts.

Set to 0 for no limit.

Can also be set via the RACK_MULTIPART_TOTAL_PART_LIMIT environment variable.

Changelog

See CHANGELOG.md.

Contributing

See CONTRIBUTING.md for specific details about how to make a contribution to Rack.

Please post bugs, suggestions and patches to GitHub Issues.

Please check our Security Policy for responsible disclosure and security bug reporting process. Due to wide usage of the library, it is strongly preferred that we manage timing in order to provide viable patches at the time of disclosure. Your assistance in this matter is greatly appreciated.

Thanks

The Rack Core Team, consisting of

Aaron Patterson tenderlove
Samuel Williams ioquatix
Jeremy Evans jeremyevans
Eileen Uchitelle eileencodes
Matthew Draper matthewd
Rafael FranÃ§a rafaelfranca

and the Rack Alumni

Ryan Tomayko rtomayko
Scytrin dai Kinthra scytrin
Leah Neukirchen leahneukirchen
James Tucker raggi
Josh Peek josh
Michael Fellinger manveru
Santiago Pastorino spastorino
Konstantin Haase rkh

would like to thank:

Adrian Madrid, for the LiteSpeed handler.
Christoffer Sawicki, for the first Rails adapter and Rack::Deflater.
Tim Fletcher, for the HTTP authentication code.
Luc Heinrich for the Cookie sessions, the static file handler and bugfixes.
Armin Ronacher, for the logo and racktools.
Alex Beregszaszi, Alexander Kahn, Anil Wadghule, Aredridel, Ben Alpert, Dan Kubb, Daniel Roethlisberger, Matt Todd, Tom Robinson, Phil Hagelberg, S. Brent Faulkner, Bosko Milekic, Daniel RodrÃguez TroitiÃ±o, Genki Takiuchi, Geoffrey Grosenbach, Julien Sanchez, Kamal Fariz Mahyuddin, Masayoshi Takahashi, Patrick Aljordm, Mig, Kazuhiro Nishiyama, Jon Bardin, Konstantin Haase, Larry Siden, Matias Korhonen, Sam Ruby, Simon Chiang, Tim Connor, Timur Batyrshin, and Zach Brock for bug fixing and other improvements.
Eric Wong, Hongli Lai, Jeremy Kemper for their continuous support and API improvements.
Yehuda Katz and Carl Lerche for refactoring rackup.
Brian Candler, for Rack::ContentType.
Graham Batty, for improved handler loading.
Stephen Bannasch, for bug reports and documentation.
Gary Wright, for proposing a better Rack::Response interface.
Jonathan Buch, for improvements regarding Rack::Response.
Armin RÃ¶hrl, for tracking down bugs in the Cookie generator.
Alexander Kellett for testing the Gem and reviewing the announcement.
Marcus RÃ¼ckert, for help with configuring and debugging lighttpd.
The WSGI team for the well-done and documented work they've done and Rack builds up on.
All bug reporters and patch contributors not mentioned above.

License

Rack is released under the MIT License.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

Top Related Projects

Quick Overview

Pros

Cons

Code Examples

Getting Started

Competitor Comparisons

Pros of Sinatra

Cons of Sinatra

Code Comparison

Summary

Pros of Rails

Cons of Rails

Code Comparison

Summary

Pros of Express

Cons of Express

Code Comparison

Pros of Django

Cons of Django

Code Comparison

Pros of Spring Framework

Cons of Spring Framework

Code Comparison

Pros of Fastify

Cons of Fastify

Code Comparison

Key Differences

Use Cases

Community and Ecosystem

Convert designs to code with AI

README

Version support

Rack 3.1

Rack 3.0

Rack 2.2

Installation

Usage

Supported web servers

Rackup

Supported web frameworks

Available middleware shipped with Rack

Convenience interfaces

Configuration

RACK_QUERY_PARSER_BYTESIZE_LIMIT

RACK_QUERY_PARSER_PARAMS_LIMIT

param_depth_limit

multipart_file_limit

multipart_total_part_limit

Changelog

Contributing

See Also

rackup

rack-contrib

rack-session

Thanks

License

Top Related Projects

Convert designs to code with AI

`RACK_QUERY_PARSER_BYTESIZE_LIMIT`

`RACK_QUERY_PARSER_PARAMS_LIMIT`

`param_depth_limit`

`multipart_file_limit`

`multipart_total_part_limit`

`rackup`

`rack-contrib`

`rack-session`