Roughly 1/3 of the internet runs on httpd, but it seems like a lot of developers have no idea how to configure it, let alone remember it exists.
Having to explain what FastCGI is or basic httpd directives is something I feel like I’m doing more and more.
@gmazzap "Modern PHP but like it's 2005, First Edition"
Though there's a lot of times I feel PHP is finally reaching that "we're getting too complicated for our own good" in terms of ecosystem. The fact PHP _didn't_ need lots of tooling was a bonus, and while it's still simpler than something like a TS toolchain.... I see the train coming down the tracks.
@alanstorm A wider audience, but much of it is the abstraction of services because of things like containers. "Stuff works when I launched the container" hits the nail on the head.
Case in point, was working with DevOps and had to explain that PHP frameworks don't govern what port we listen on, and that a real web server is needed. That launched into a discussion on (Fast)CGI + server config. Then because we were using httpd, discussing directives.
This was with people that do TS and golang.
@dragonmantank _nod_ -- I've run into two flavors of this -- "I'm a software engineer, other people figure out how to operationalize my code" and then folks from the Node.js/GoLang/other-language where you end up coding small web servers yourself every day.
Related: Back in my New Relic days I found myself having to explain (and justify?!) the FastCGI and mod_php split and apache extensions generally to a bunch of unimpressed C programmers and the vibe was pretty out there.
@alanstorm It's funny, because I remember when we hated others operationalizing our code due to sysadmins not understanding how to handle code bases.
The number of times people would get the wrong versions of PHP or MySQL, or outdated distros because "that's company policy/what do you mean you need X?/I thought you were doing perl" was what got me into sysadmin because I _hated_ dealing with other groups to deploy my code.
@dragonmantank So… when I use httpd, I normally use mod_php and let httpd take care of all the processes. Is there a reason to use FastCGI over that?
At $dayjob, we use nginx with PHP-FPM for PHP and Nest.js/Express for Node.js. I know I’m the odd one out with my love for the simplicity of mod_php, but I don’t think many of the other popular languages had something as simple, so they had to go the FastCGI route.
@mwop @ramsey Yeah, that's the biggest reason. Of you want a single web server pushing out to multiple languages via FastCGI.
Performance-wise it's pretty much equal between the two at the end-of-the-day. Most of the time I still do mod_php just because it's a single container and setup, especially to get started. I'd rather reduce complexity than worry about .01ms of response time.
@dragonmantank @ramsey Where it gets interesting is it allows you to add another web server — e.g., to update to a newer version to pick up a security fix, or to change configuration — and then change over your load balancer to point to that instance instead of the old one. Zero down-time for those hitting your site(s)/application(s).
Again, these are mainly problems for those who need scale or uptime guarantees. For the vast majority, it's likely overkill.
@dragonmantank @ramsey That said: I've played a lot with Caddy, and there are things I appreciate about it:
- ACME built-in. I literally need to do nothing to automatically have TLS, and HSTS etc are easy to config.
- I can route to S3-compatible storage for static assets.
- I can connect FastCGI pools or reverse proxy with 1 config directive.
I can do Apache configuration pretty easily, and I'm reasonably versed in nginx. But Caddy has learned from each, and hits some sweet spots.
@ramsey @dragonmantank That was what Apache was like back in the late 90s early 00s as well, Ben.
Oh, crap, did I just type that?
I'm an old.
@dragonmantank @ramsey @mwop im still suffering finding apache 2.2 docs now that 2.4 has been pushed (finally, omg) mainstream in all the repos.
and there are enough differences to be annoying. good ones. but.
@dragonmantank @ramsey @mwop also been keeping my eye on https://frankenphp.dev/
it is caddy based though and i just havent been able to dedicate the time to research the things i know i need to know across topics like app config, scaling, and attack mitigation.
@dragonmantank @ramsey I consider this A Good Thing™. httpd modules locked you into a single web server ecosystem, while FastCGI is a protocol, allowing for more solutions and options.
I also personally appreciate languages/runtimes that can create HTTP servers for this reason. You can do things like security and load balancing in front of them, using web servers that then reverse proxy.
Protocols > lock-in.
@assertchris I still think it's important to have an _understanding_ of the stack though, as the more moving pieces you have the more places things can break. It's much easier to troubleshoot when you have a basic knowledge of how things fit together.
Am I advocating everyone roll their own server by hand? No, of course not.
dragonmantank 
Giuseppe Mazzapica
alana storm 🏳️⚧️
Ben Ramsey
Matthew Weier O'Phinney
bob.php 
Adam Harvey
Stephan Hochdörfer
assertchris