> It has no place in todays world except of educational use.

That's overly strong. I will create a CGI app every now and then. I can use basically any language I want. Not a lot of thought has to go into it. As the article says, it's a simple approach that makes sense for those of us that aren't so familiar with web development (we're usually making those apps for ourselves). In particular, the "you can never have too many dependencies" philosophy of modern web developers is strange to me.

I think its just that everyone on hacker news likes to pretend they have to scale to the size of google even though most people aren't even in the same ballpark.

Currently trying to order room service in a hotel from xxxxx.menu.org.Uk

It isn’t loading, just sits there spinning. Pile of shit. I wish they’d chosen to write the service as a reliable cgi rather than some web framework where errors are eaten and hidden in Ajax calls.

Uber eats let’s me place the order then vanishes when it comes to paying.

Nandos yesterday told me error UK03 when I tried ordering in the restaurant, slightly better, but perhaps those more concerned with scaling to a million concurrent users could deal with 1000 reliably first.

I mean, on the other hand you could be dealing with an unreliable CGI-served page where errors are eaten and hidden in ajax calls, wishing they’d used a reliable javascript framework[1] instead.

[1]: an oxymoron, I know

The point is that people spend far too much effort worrying about the ten millionth user rather than concentrating on making a reliable product for the hundred or two they have. “Can’t use cgi because we can only support 100 concurrent users per VM” is meaningless, concentrate on the real problem of building a site that doesn’t crash out silently

It is not necessarily about scaling the number of requests, but scaling for developers & security. You will pretty soon hit a point where you need smarter cookies access, CSRF protection, multipart/form-encoded POST requests etc. Sure, you could implement everything yourself, but this is stuff those "frameworks" already solved.

I think it is also worth to mention there are plenty of "slim/light" frameworks that do very little (i.e. take care of threading, provide html request/response as writable streams, have the http headers parsed for you into a Map-like data structure etc.). Those lightweight frameworks exist i.e. express without middleware (nodeJS), Nancy (.NET), Flask (Python) etc. The "full-blown" counterparts would be ASP.NET or Django which bring far more to the table than you might need.

Definitely overly strong. I don't personally use CGI because I've got a whole toolbox of pre-built starters that can scale if needed. Still, I've worked many projects that needed a simple, infrequently used microservice to do something that couldn't be done inside of an enterprise management system (read SAP, CRM, Salesforce). CGI would be an easy to maintain and perfectly acceptable solution.

Hum, I beg to differ. I write small utilities with web frontends that run on my PC's local apache using CGI. A couple of devs from my team and I are the only persons susceptible to run them, and it's plenty fast enough.

Even for a web-facing tool, as long as it doesn't receive more than a couple requests per second CGI is good enough, and that probably represents most web apps in existence. YAGNI principle applies, too. Most people don't work at Google of Facebook or hyper-scaling startups. A fantastic number of real-world development consists in building boring web front-ends for in-house use of random companies; and 99% of accounting forms or support tickets won't require huge performance, even running with CGI.

I'll fully admit I'm not as well versed in web programming as it's not my specialty, but aren't serverless functions (e.g. AWS Lambda) essentially the same concept?

I understand that they can solve the problem of horizontal scale as they are spawning a container rather than just a process, but surely if you started with CGI scripts it would be easier to move if you needed to at a later date.

How about FCGI?

I use FCGI with Go programs. FGCI is an orchestration system. Each worker process has a subroutine that's called when there's an incoming request, so the FCGI processes are reused for more than one task. The FCGI server will fire up more worker processes when needed, and ask them to exit when there's no work for a while. If a worker process crashes, a fresh copy is started. Every few minutes, each worker process is told to exit, so if you have a memory leak, the problem is contained.

Once you've switched to hard-compiled Go, vs. some interpreted language, you've obtained most of the possible speedups.

That's really all you need. I have a moderately busy server that's been up for over a thousand days without a reboot or restarting the FCGI service running under Apache.

You have to have a huge load before FCGI, multiple servers, a load balancer, and back-end database machines are not enough. Wikipedia used to run on something like that, until they hired too many people and had to keep them busy.

Why don't you use the golang http server instead?

I used to use FGCI with perl. I never thought it could improve performance of GO as handler routines are already "running".

So the remaining advantage to use FCGI with Go is that memory leaks would never be an issue?

We used fcgi at my last company in routers. When you make a request to a router's embedded webserver internally it forwards the request via unix sockets to a persistent CGI process which sends back the JSON. Worked really well and had a tiny memory footprint.

It's a bit better but one process can only process one request at a time. You need a lot more processes compared to a http framework processing http requests in parallel.

How do those web frameworks gain the ability to process things in parallel? What prevents a ‘single process’ from adopting those same methods?

Those web frameworks are lower level and have an embedded HTTP server designed to process things in parallel. It's in the standard library in golang or nodejs for example.

Sounds like one can use libuv in a CGI project and gain the same parallelization.

... and end up with something like Node.js or Vert.x.

Usually you have a thread pool (threads have startup costs too), monitor the server socket and assign incoming connections to one of the worker threads. Nonblocking architectures that do everything in a single thread also exist.

It's very common even to do this: just use Apache `mod_proxy` (or something more specialised) to forward requests to a backend server such as Apache Tomcat.

Most people don't need to worry about 'parallel' - that's the point of the OP.

Need a site to order XYZ? Unless you are a mega chain, small biz doesn't need to do anything more complex than serve its 100 customers reliably. Most 'modern' stuff is wasted abstraction for complexity which does not exist.

how many features can your process accumulate before it's called a framework?

Fcgi apps can handle requests in parallel in a single process just fine, as long your environment supports it.

You are right, fastcgi supports multiplexing. It seems that it's not implemented very often though.