CGI: Ruby's Bare Metal
In this technical retrospective (2015), @mperham shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 64 points
TOTAL DISCUSSIONS 14 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.
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'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.
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
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.