Add ruby equivalent of node.js app

[Davidslv]

Hi @antonputra,

First off, I really enjoyed your YouTube video on comparing Ruby and Node.js performance (https://www.youtube.com/watch?v=Qp9SOOtgmS4). It's clear you put a lot of thought into demonstrating real-world differences, and I appreciate how it highlights practical insights for developers choosing between the two. Videos like yours are super helpful for the community!

I've been tinkering with the ruby setup and came up with what I think could be an even closer apples-to-apples comparison. I'd love to get your take on it—maybe it could complement what you've already shown us. Here's why I believe ruby-app-node-equivalent aligns so well as an alternative for the Ruby side:

1. Architecture Similarity

This keeps things balanced by mirroring the straightforward, low-level approach on both sides, which really lets the languages shine through without extra frameworks getting in the way.

• node-app: Relies on Node.js's built-in http module for that raw, efficient handling. Keeps dependencies light with just postgres, prom-client, and js-yaml. Routing is handled directly in a simple structure: app.js, db.js, devices.js, metrics.js, config.js.

• ruby-app-node-equivalent: Matches that vibe using WEBrick (Ruby's equivalent low-level web interface). Dependencies stay minimal: pg, prometheus-client, rack, yaml. It handles HTTP requests directly with manual routing in a parallel file setup: app.rb, db.rb, devices.rb, metrics.rb, config.rb.

• ruby-app: Builds on a high-performance server like Iodine, with extras like connection_pool, oj, rage-iodine, standalone_migrations, and rake—great for optimized scenarios, but it shifts the focus a bit.

2. Dependency Comparison

By keeping dependencies equivalent, we can see how each language performs its core tasks without one side having an edge from specialized tools.

Feature	node-app	ruby-app-node-equivalent	ruby-app
HTTP Server	Built-in http	Built-in webrick or rack	rage-iodine (external)
Database	postgres	pg	pg + connection_pool
JSON	Built-in JSON	Built-in JSON	oj (optimized)
Metrics	prom-client	prometheus-client	prometheus-client
Config	js-yaml	Built-in yaml	Built-in yaml

3. Code Complexity

The code stays concise and direct in both minimal versions, making it easier to follow and compare line-by-line.

• node-app (98 lines):

  const server = http.createServer({ keepAliveTimeout: 60000 }, (req, res) => {
    if (req.url === "/metrics") { ... }
    if (req.url === "/healthz") { ... }
    // Direct routing
  });

• ruby-app-node-equivalent (158 lines):

  class App
    def call(env)
      req = Rack::Request.new(env)
      case req.path
      when '/metrics' then ...
      when '/healthz' then ...
      # Direct routing
    end
  end

• ruby-app: Incorporates patterns like models (Device.create, Device.list), migrations, connection pooling, and optimized JSON with Oj—awesome for scaling, but adds layers that make direct comparison trickier.

4. Fair Performance Comparison

Starting from similar minimal baselines lets us isolate language differences more clearly, which I think aligns perfectly with the educational goal of your video.

• node-app vs. ruby-app-node-equivalent: Both keep it lean with direct HTTP handling—no extras tipping the scales.
• node-app vs. ruby-app: The optimizations in ruby-app (like Iodine and pooling) are smart for real-world use, but they create different starting points.

5. Purpose Alignment

Your node-app is spot-on for a simple, educational demo, and ruby-app-node-equivalent aims to match that exactly—minimal and focused on comparison.

Summary

In short, ruby-app-node-equivalent could enhance the comparison by matching node-app's simplicity: similar low-level HTTP, minimal dependencies, direct code structure, and a shared focus on learning rather than production tweaks. It's like pitting two basic sedans against each other to see which handles the road best, keeping the spotlight on the engines (languages) themselves.

What do you think? Does this resonate with what you were going for in the video? I'd be thrilled to hear your feedback and hopefully see another video where you show us again the comparisons!

Thanks again for the great content, and looking forward to your thoughts.

Best,
David