I'm still using FastCGI! It works well on Dreamhost.<p>The Python support is not good! In theory you just write a WSGI app, and it will work under a FastCGI wrapper.<p>But I had to revive the old "flup" wrapper, since Dreamhost has Python 2. I downloaded an older tarball and build it myself.<p>Use case: I parse thousands of shell scripts on every release and upload the results as a ".wwz" file, which is just a zip file served by a FastCGI script.<p><a href="https://www.oilshell.org/release/0.8.1/test/wild.wwz/" rel="nofollow">https://www.oilshell.org/release/0.8.1/test/wild.wwz/</a><p>So whenever there's a URL with .wwz in it, you're hitting a FastCGI script!<p>This technique makes backing up a website a lot easier, as you can sync a single 50 MB zip file, rather than 10,000 tiny files, which takes forever to stat() the file system metadata.<p>It's more rsync-friendly, in other words.<p>I also use it for logs in my continuous build: <a href="http://travis-ci.oilshell.org/jobs/" rel="nofollow">http://travis-ci.oilshell.org/jobs/</a><p>-----<p>Does anyone know of any other web hosts that support FastCGI well? I like having my site portable and host independent. I think FastCGI is a good open standard for dynamic content, and it works well on shared hosting (which has a lot of the benefits of the cloud, and not many of the downsides).
I went a step further and spent most of my free time this year writing CGI/C apps.<p>This was not nostalgia either : the reason for doing that is because I was writing webapps for my pinephone. Toying with the phone, I decided I wanted my apps to be webapps rather than GTK apps, so that I can access them either from mobile or laptop (through local network), but I didn't want to have the apps running all the time, in order for them to consume less energy (which directly translates to battery lifetime on a mobile). Turns out that CGI is perfect for that : the only process always running are nginx and fcgiwrap, then all my apps are started only on demand, for the lifetime of the request.<p>I did expect a big performance hit, but I was surprised it was not so bad. I guess that's because they are C app rather than written in languages which require loading an interpreter before running anything. One app that I rewrote from libmicrohttpd had actually better perfs (although it was the first time I used libmicrohttpd, so it was probably something I didn't do correctly).
Don't worry, I don't think these lessons were forgotten -- we've made your way back full circle already with "serverless functions" if you squint a little bit.
I disagree a lot with this article's opinions on PHP. It sounds like coming at it from the perspective of someone who hasn't used it in over a decade. Modern PHP with frameworks is just about as good as it gets for web development.<p>Edit: oh lol, this was written in 2002, alright, that confirms that.
I can’t find any good information on implementing a fastcgi compliant server. Does anyone happen to have information about how to do this? I think it would work well for some applications I have and I can’t find anything to increase my know how to take in incoming fastcgi requests. Think nodejs in particular but language agnostic documents would be best
~15 years ago, I was tasked with implementing FastCGI support for a webserver I was writing in C++, so that it could proxy some downstream crud stuff written in Python. After mulling over it for a couple of days, I ended up implementing SCGI[1] support instead. SCGI is like FastCGI, but a lot simpler to parse, IIRC.<p>[1]: <a href="https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface" rel="nofollow">https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interfac...</a>
FastCGI was one of my favorite silver bullets for improving the speed of /cgi-bin/ programs. I used to have slow machines where the Perl interpreter startup time would be significant, so rewriting the script around an fcgi loop made a huge difference. The script could stick around serving requests, and if you feared a memory leak, you could just exit() after a hundred requests or whatever, and the FastCGI spawner would restart them on the next request.<p>It wasn't as fast as something like mod_perl [1], but much easier to integrate with quickly hacked scripts, as long as you were lexically scoping everything with my() and not screwing up your globals. Fun times.<p>[1] <a href="https://www.perlmonks.org/?node_id=108008" rel="nofollow">https://www.perlmonks.org/?node_id=108008</a>
Its too bad this never got more traction, I always thought the ability to define roles was an incredibly smart and useful feature. Defining 'authorizer' and 'filter' allows you to stack all sorts of independent apps - responder provides data, filter does rendering, authorizer is SSO, for example.<p>Wprth mentioning that Openbsd does have fastcgi support in it's httpd server, but only supports the responder role
Kapow is great to transform shell scripts in web apps:<p><a href="https://github.com/BBVA/kapow" rel="nofollow">https://github.com/BBVA/kapow</a>
After hearing about CGI I became a bit obsessed with its simplicity and started writing my blog[1] as a CGI app, eventually incorporating a FastCGI library later.<p>Performance-wise I don't know how it would compare to other options, but I think it's a great way to expose C/C++ code to the web.<p>[1]: <a href="https://github.com/cluoma/bittyblog" rel="nofollow">https://github.com/cluoma/bittyblog</a>
Java servlets were likely inspired by FastCGI, and WSGI (Web Server Gateway Interface, Python) is known to be inspired by both, so I doubt that's true. There were just more convenient solutions than having to write the IPC part yourself.
I love fastcgi - a quick and easy way to have lightning fast C/C++ backends. Unfortunately there aren't many maintained fastcgi libraries out there.
It's interesting to revisit technologies I couldn't comprehend when I got started in programming, way back in 1995 or so. Now I finally understand exactly what's going on.
So we've just rediscovered stateful web applications. Been doing those since early 90's and still doing it now (well among lots of other things). The difference for me is that I've never went for FastCGI. I would instead embed HTTP server in the application itself. In the beginning when the whole concept was young said server would face the outside world directly, now it is hiding behind reverse proxies like Nginx.
There is still <a href="https://en.wikipedia.org/wiki/Apache_JServ_Protocol" rel="nofollow">https://en.wikipedia.org/wiki/Apache_JServ_Protocol</a> which Apache, nginx and IIS support
Wow, quite a blast from the past!<p>Does anyone know how FastCGI compares to performance with fast VM languages that self host like Go, C#, Java? I remember it being fast compared to CGI with Perl... But thats a pretty low bar