Rage: Add framework

[p8]

No description provided.

[BennyFranciscus]

Hey @p8, nice to see Rage getting an entry! Fiber-based non-blocking I/O on Ruby is a cool approach. A few things I spotted:

Missing files:

• config/puma.rb — Dockerfile CMD references puma -C config/puma.rb but this file isn't in the PR. Without it, Puma will use defaults which means it won't bind to 0.0.0.0:8080. Needs at minimum:

bind 'tcp://0.0.0.0:8080'
threads ENV.fetch('RAILS_MAX_THREADS', 3).to_i, ENV.fetch('RAILS_MAX_THREADS', 3).to_i
workers ENV.fetch('WEB_CONCURRENCY', 0).to_i
preload_app!

• config/environment.rb — config.ru does require_relative 'config/environment' but there's no config/environment.rb in the PR. This will crash on startup.

Missing gems in Gemfile:

• sqlite3 — controller uses SQLite3::Database for the db endpoint
• puma — used as the app server but not in the Gemfile
• json — used for JSON.parse/JSON.generate (might come bundled with Ruby 4.0 stdlib, but explicit is safer)

Potential issue with mattr_accessor:

• That's an ActiveSupport method. Does rage-rb provide it? If not, this will blow up at class load time. Regular class_attribute or just plain @@var with accessor methods might be safer.

Compression endpoint:

• send_data with disposition: :inline — worth checking if Rage supports this. If it's a Rails-specific helper, you might need render plain: sio.string with manual headers instead.

One more thing — no static-h2 in the tests list in meta.json, which is fine, but just confirming that's intentional (no TLS/H2 support in this config).

Otherwise the controller logic looks solid — same patterns as the Rails entry. Looking forward to seeing how Rage compares!

[BennyFranciscus]

Nice updates! Looking at the force-pushes, you addressed a bunch of the things I flagged:

• ✅ Switched from puma to rage -p 8080 in the Dockerfile CMD — clean
• ✅ config.ru now requires config/application instead of the missing config/environment
• ✅ sqlite3 added to Gemfile
• ✅ config/application.rb with proper Rage setup

A couple things still worth checking:

1. mattr_accessor in the controller — does rage-rb provide this? If it comes from ActiveSupport and Rage bundles it, you're good. If not, a simple class << self; attr_accessor ... end would be safer.

2. send_data with disposition: :inline in the compression endpoint — same question, does Rage support this method? If not, you could do something like:

response.headers["Content-Type"] = "application/json"
response.headers["Content-Encoding"] = "gzip"
render plain: sio.string

3. meta.json has "engine": "puma" but you're now using Rage's built-in server (which is Iodine under the hood iirc). Might want to update that to "iodine" or "rage" to keep it accurate.

4. Minor: no "db" in the tests list in meta.json, but the endpoint is implemented. Intentional?

Getting close though 👍

[BennyFranciscus]

Good progress on the refactor! The class-level instance vars with def self. accessors is much cleaner than mattr_accessor.

Spotted one bug though:

Missing accessor for @dataset_items — you define:

def self.db_available = @db_available
def self.large_json_payload = @large_json_payload

But @dataset_items has no accessor. The json_endpoint action calls self.class.dataset_items which will be nil → always returns 500.

Add:

def self.dataset_items = @dataset_items

Also meta.json still has "engine": "puma" — Rage uses Iodine under the hood, so "iodine" or "rage" would be more accurate.

[BennyFranciscus]

Still seeing the two things from my last review after the latest push:

1. Missing dataset_items accessor — you have def self.db_available and def self.large_json_payload but no def self.dataset_items. The json_endpoint action calls self.class.dataset_items which will be nil → instant 500. Just add:

def self.dataset_items = @dataset_items

2. meta.json engine — still says "puma". Since you're using Rage's built-in server (Iodine under the hood), "iodine" or "rage" would be more accurate.

Minor things (non-blocking):

• "db" not in the tests list in meta.json but the endpoint is implemented — intentional?
• send_data in the compression endpoint — if that works in Rage, great. If not, the render plain: + manual headers approach from my earlier comment is a safe fallback.

Getting really close though — just that accessor and the engine field and this should be good to go 🚀

[BennyFranciscus]

Latest push still has the same two things:

1. Missing dataset_items accessor — line 27 area has def self.db_available and def self.large_json_payload but no def self.dataset_items. The json endpoint calls self.class.dataset_items on line 54 → returns nil → 500 every time. One-liner fix:

def self.dataset_items = @dataset_items

2. meta.json engine — still says "puma". Rage uses Iodine under the hood, so "iodine" or just "rage" would be more accurate.

Both are tiny fixes, happy to approve once they're in 👍

[BennyFranciscus]

Nice, the dataset_items accessor is in there now 👍

Just the one remaining thing: meta.json still has "engine": "puma" — since Rage uses Iodine under the hood (not Puma), updating that to "iodine" or "rage" would keep the metadata accurate.

Once the engine field is updated, this is good to go from my side 🚀

[BennyFranciscus]

LGTM! Both issues resolved — dataset_items accessor is in and meta.json correctly shows "engine": "iodine". Controller logic looks solid, Rage entry is ready to benchmark 🚀

[BennyFranciscus]

Re-approving after force push — diff still looks great. Clean Rage entry with proper per-request JSON computation, level 1 gzip compression, and fiber-local SQLite connections. Good to go 👍

[BennyFranciscus]

Clean implementation. Uses Rage's controller API, standard routing, framework-level serialization. jemalloc + YJIT are documented Ruby production settings. Gzip level 1 manually applied — correct. JSON total computed per-request as required. SQLite mmap pragma is standard. No rule violations here. 👍

[BennyFranciscus]

Re-approving after latest force push — everything still looks good. Rage entry is clean and ready to go 👍