Puma VS Rack

As we use Puma as our webserver for our rails application, I quickly went to Puma's config file which typically resides in config/puma.rb. The config was set as

They do! It's in the first section of the readme on the repo:

Start with service with systemd

# Use the Puma web server [https://github.com/puma/puma] gem "puma", "~> 5.0" # Build JSON APIs with ease [https://github.com/rails/jbuilder] # gem "jbuilder" gem 'rack-cors' gem "devise" gem "jsonapi-serializer" gem 'devise-jwt' gem 'active_model_serializers' gem 'followability' gem 'dotenv-rails', groups: [:development, :test, :production] gem 'sprockets' # Use Redis adapter to run Action Cable in production # gem "redis", "~> 4.0" # Use Kredis to get higher-level data types in Redis [https://github.com/rails/kredis] # gem "kredis" # Use Active Model has_secure_password [https://guides.rubyonrails.org/active_model_basics.html#securepassword] # gem "bcrypt", "~> 3.1.7" # Windows does not include zoneinfo files, so bundle the tzinfo-data gem gem "tzinfo-data", platforms: %i[ mingw mswin x64_mingw jruby ] # Reduces boot times through caching; required in config/boot.rb gem "bootsnap", require: false # Use Active Storage variants [https://guides.rubyonrails.org/active_storage_overview.html#transforming-images] # gem "image_processing", "~> 1.2" # Use Rack CORS for handling Cross-Origin Resource Sharing (CORS), making cross-origin AJAX possible # gem "rack-cors" group :development, :test do # See https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-debug-gem gem "debug", platforms: %i[ mri mingw x64_mingw ] end group :development do gem "sqlite3", "~> 1.4" # Speed up commands on slow machines / big apps [https://github.com/rails/spring] # gem "spring" end group :production do gem 'pg' end

source "https://rubygems.org" git_source(:github) { |repo| "https://github.com/#{repo}.git" } ruby "3.1.0" # Bundle edge Rails instead: gem "rails", github: "rails/rails", branch: "main" gem "rails", "~> 7.0.4", ">= 7.0.4.2" # The original asset pipeline for Rails [https://github.com/rails/sprockets-rails] gem "sprockets-rails" # Use sqlite3 as the database for Active Record gem "sqlite3", "~> 1.4" # Use the Puma web server [https://github.com/puma/puma] gem "puma", "~> 5.0" # Use JavaScript with ESM import maps [https://github.com/rails/importmap-rails] gem "importmap-rails" # Hotwire's SPA-like page accelerator [https://turbo.hotwired.dev] gem "turbo-rails" # Hotwire's modest JavaScript framework [https://stimulus.hotwired.dev] gem "stimulus-rails" # Build JSON APIs with ease [https://github.com/rails/jbuilder] gem "jbuilder" gem "mongoid" gem "mongoid-grid_fs" gem 'bootstrap', '~> 5.2.2' #sourced from https://github.com/twbs/bootstrap-rubygem gem 'rack-cors' # Windows does not include zoneinfo files, so bundle the tzinfo-data gem gem "tzinfo-data", platforms: %i[ mingw mswin x64_mingw jruby ] # Reduces boot times through caching; required in config/boot.rb gem "bootsnap", require: false

That doesn't mean one excludes the other. Gems like Puma use the instance_eval method for their configuration file.

Anyway I did it: https://github.com/puma/puma/issues/3003 It's quite more complicated: https://github.com/puma/puma/issues/2999 A fix is in progress: https://github.com/puma/puma/pull/3002

Because of its lightweight and Rack-based architecture, Sinatra is great for building APIs, mountable app engines, command-line tools, and simple apps like the one we'll build in this tutorial.

Since you mentioned Sinatra and Rails I assume you're talking about web apps. In that case you want to build a Rack Application. That's where web frameworks' responsibility ends.

I'm thinking about building a website that scrapes release notes from sources like https://community.ui.com/releases, https://github.com/rack/rack/blob/main/CHANGELOG.md, https://developer.android.com/about/versions/13/release-notes etc, and cleans them up & formats into the same format so they can be searched a lot easier.

It seems like the best place to start would be for folks who read HN since we refer to these quite a bit day-to-day to figure out what changes in software, apps, etc. Let's open this up with a few questions:

1. Would you find a service like this useful? Why or why not?

2. What release notes would you want to have formatted into the same thing and why?

3. What features or capabilities would you like to see a service like this do? e.g. would you like to select multiple "products/apps/whatever" and see their release notes in one timeline? Side-by-side? etc. etc. etc.

In Elixir world, Plug is a bit similar to Rack in Ruby. Official documentation describes Plug as:

The spec for Ruby's Rack is another good reference for how a Ruby webserver is expected to work.

You've been around in the Rails world for a while. You know your way around rails. But you keep hearing this word 'Rack' and don't really understand what it is or what it does for you. You try to read the documentation on the Rack Github repository or the Rails on Rack guides, but the only thing it does is add to the confusion.

Begin with writing a rack-middleware. Rack is a standard library for writing a web server. The main structure is simple. Here is an example:

Coming from the Ruby ecosystem, a lot of this played out similarly to how the Rack[1] middleware conventions developed in the early Rails v1 and v2 days. Prior to Rack there was a lot of fragmentation in HTTP server libraries, post-Rack everything more or less played nicely as long as libraries implemented Rack interfaces.

I don't write Rust professionally, but it was a bummer seeing that this seems to be a place that was figured out (painfully) in ecosystems used heavily for web development--Javascript and Elixir have their own Rack equivalents[2][3]. I hope that Tower plays a similar role to unify the library ecosystem in Rust.

1. https://github.com/rack/rack

2. http://expressjs.com/en/guide/writing-middleware.html

3. https://github.com/elixir-plug/plug