5 ms·

I love the simplicity of CGI, it was ~2002 when I read about it in a book on Linux and had my first server-side generated HTML output a couple of minutes later.

I love the simplicity of CGI, it was ~2002 when I read about it in a book on Linux and had my first server-side generated HTML output a couple of minutes later. But: It has no place in todays world except of educational use. Especially the fact, that every HTTP request would spawn a full new process makes it unfeasible for any serious webapp.

teddyh 5y ago
How about FCGI?
- umvi 5y ago
  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.
- speedgoose 5y ago
  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.
  - jagged-chisel 5y ago
    How do those web frameworks gain the ability to process things in parallel? What prevents a ‘single process’ from adopting those same methods?
    - smaudet 5y ago
      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.
    - speedgoose 5y ago
      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.
      - jagged-chisel 5y ago
        Sounds like one can use libuv in a CGI project and gain the same parallelization.
        samus 5y ago
        ... and end up with something like Node.js or Vert.x.
    - alisonkisk 5y ago
      how many features can your process accumulate before it's called a framework?
    - samus 5y ago
      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.
  - technothrasher 5y ago
    Fcgi apps can handle requests in parallel in a single process just fine, as long your environment supports it.
    - speedgoose 5y ago
      You are right, fastcgi supports multiplexing. It seems that it's not implemented very often though.
- Animats 5y ago
  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.
  - swamp_gas 5y ago
    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?
  - speedgoose 5y ago
    Why don't you use the golang http server instead?
bachmeier 5y ago
> 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.
- iratewizard 5y ago
  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.
- bawolff 5y ago
  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.
  - midasuni 5y ago
    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.
    - whelming_wave 5y ago
      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
mxb 5y ago
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.
wazoox 5y ago
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.

teddyh 5y ago

How about FCGI?

umvi 5y ago
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.
speedgoose 5y ago
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.
- jagged-chisel 5y ago
  How do those web frameworks gain the ability to process things in parallel? What prevents a ‘single process’ from adopting those same methods?
  - smaudet 5y ago
    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.
  - speedgoose 5y ago
    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.
    - jagged-chisel 5y ago
      Sounds like one can use libuv in a CGI project and gain the same parallelization.
      - samus 5y ago
        ... and end up with something like Node.js or Vert.x.
  - alisonkisk 5y ago
    how many features can your process accumulate before it's called a framework?
  - samus 5y ago
    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.
- technothrasher 5y ago
  Fcgi apps can handle requests in parallel in a single process just fine, as long your environment supports it.
  - speedgoose 5y ago
    You are right, fastcgi supports multiplexing. It seems that it's not implemented very often though.
Animats 5y ago
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.
- swamp_gas 5y ago
  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?
- speedgoose 5y ago
  Why don't you use the golang http server instead?

bachmeier 5y ago

> 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.

iratewizard 5y ago
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.
bawolff 5y ago
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.
- midasuni 5y ago
  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.
  - whelming_wave 5y ago
    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

mxb 5y ago

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.

wazoox 5y ago

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.