Hacker News new | ask | show | jobs
by qbasic_forever 1334 days ago
Sure but developers don't want to bifurcate their service code and releases into a simple version using CGI and a dedicated app server version for when CGI doesn't scale for them or their users. They just want to write one python web app and run it everywhere.

There's no way a CGI app can reach a million requests a second on the same hardware that a nodejs (single thread, worker loop) would take to do 1M RPS. Processes have a lot of overhead. Almost no one needs 1M RPS but it cannot be waived away that CGI is perfect for everything.

2 comments

That's the problem: people absolutely exaggerate how much their site will need. I didn't say CGI is perfect for everything, I said it is enough for 80% of the websites, for the entire lifetime of said sites. Your blog won't suddenly reach Alexa top 100. Your family sharing photo site will remain seen by your relatives only. You HOA website won't become a trending topic overnight.
Yep. Also, sharing resources between connections is (at best) very difficult using CGI, and its trivially easy using a stand-alone app server. You can just set up a global variable at process startup and you're done. (This is useful in just about every web app I've ever written - eg for the connection to a database, cached resources, cached renders of common pages, in-memory only security tokens, etc).

I also find the modern approach much easier to reason about and debug. I don't need Apache + fastCGI + php + php fastCGI + apache configuration to get started. I can just run `node server.js` and my web app works.

The fact that it also scales much better is a cherry on top.

> Also, sharing resources between connections is (at best) very difficult using CGI, and its trivially easy using a stand-alone app server. You can just set up a global variable at process startup and you're done

You can pass environment variables to CGI scripts as well. In fact, that's exactly how CGI works. Shared resources can be cached in memory through redis, although a shared file (for example sqlite) is enough in many cases.

> I don't need Apache + fastCGI + php + php fastCGI + apache configuration to get started

I'm talking about CGI, not fastCGI

Environment variables can’t store a TCP connection to a database or a pre rendered HTML string.

In the latter case you could use redis, but that’s a poor, inconvenient, inefficient replacement for a global variable.

Again, I'm not saying CGI is the fastest but that it is fast enough. Opening a new connection (or better yet, using SQLite), reading a file that contains a prerendered HTML string are fast enough for most use cases