I recommend CGI instead of web frameworks
halestrom.net
I recommend CGI instead of web frameworks
1–10 of 89 posts
Re: I recommend CGI instead of web frameworks
#2I 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.
Re: I recommend CGI instead of web frameworks
#3I 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.
How about FCGI?
Re: I recommend CGI instead of web frameworks
#4This is used a lot on routers nowadays, for certain things it's great. I'm not sure running sh in cgi-bin would work for c10m (unless you've got a lot of servers!) or sanitization etc.
Re: I recommend CGI instead of web frameworks
#5I 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.
How about FCGI?
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.
Re: I recommend CGI instead of web frameworks
#6I 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.
How about FCGI?
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.
Re: I recommend CGI instead of web frameworks
#7I 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.
> 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.
Re: I recommend CGI instead of web frameworks
#8I'll always have a soft spot for Classic ASP[0]. Makes me dream of a simpler time developing CRUD apps.
Re: I recommend CGI instead of web frameworks
#9"premature optimisation is the root of all evil" for sure, but getting a denial of service by the Google bot scanning your website, someone running Apache Bench from a smartphone on a GPRS network, or an unfortunate infinite loop client side (it happens) is not great.
I think it's fine to play with CGI to learn, but I wouldn't push that to production.
Re: I recommend CGI instead of web frameworks
#10I 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.
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.