CGI: Ruby's Bare Metal | Hacker News Reader

CGI: Ruby's Bare Metal

mikeperham.com

64 pointsmperham14 comments

I remember a number of years ago I was setting up a shared access shell machine, and came across the idea of piping pine directly into the IMAP server via domain sockets, in an on-demand fashion. It was a revelatory experience for me in the Unix way, seeing how interchangeable TCP, domain sockets, and files are in general. Even this article's example is quite a bit more abstracted than the simplest case in ruby (which itself is quite a bit more abstracted than what you can do with building blocks like `nc` and `echo`).

Being able to see that 'socket / file duality' is one the best observational powers a network-facing developer can have. It's also one of the biggest worries I have about HTTP 2.0.

CGI isn't "bare-metal", it's just the 1996 approach to dynamic web requests. The reason it continues to work in 2015 is because it's simple.

> Look at what I’m not running

Cue http://dhh-soundboard.herokuapp.com

"It goes fast, don't blink"

hahaha :)

I'm not sure what the benefits really are – 'deployment via SCP' is arguably a negative, for example!

If you really want to do something like this, do use FastCGI – and wrap it in Rack, too. That way, you'll get nice request and response objects.

Combining FastCGI and Rack? You've effectively described Phusion Passenger, because that's exactly what it is. It doesn't use the FastCGI wire protocol but how it works is exactly that: integrated in the web server, reuses a Ruby process for multiple requests to avoid the startup overhead, using Rack as the gateway interface, etc.

Yep, absolutely. In a situation like this, I would add the Passenger module to Apache and let it run a Rack script.

Indeed. The code is even simpler, and you're getting the shell out of the equation. Remember that bash bug from late last year?

Also the use of the phrase "bare metal" in reference to a ruby CGI script is pretty lulzy. I suppose thats the new normal. The embedded programmers of the world must feel pretty annoyed when people do that. I suppose they're too high on magic smoke to care.

There is much to Ruby that is not about the Web. The idea that the post is getting at is an important one: CGI as an ubiquitous interface; but the title is terrible.

Meh. "The real thing is using 3-4 gems. That’s it." - So how did those gems get on the server? How do you know which gem versions the app should use without a Gemfile(.lock), and how do the versions of gems and ruby itself get updated for bug/security fixes?

I think he's just saying, there's a time and a place for Rails, Sinatra, etc, but you can get some simple stuff done without a whole lot of overhead.

An interesting article, but the use case here is pretty esoteric. For most people a simple sinatra service w/ a reverse proxy would work just as well for a pretty minimal increase in complexity

And me thinking someone had implemented a bare metal runtime for Ruby...

Reply on news.ycombinator.com