Hacker News new | ask | show | jobs
by al_borland 7 days ago
I’m the same way, even for little side projects at work. Basic old-school PHP is effortless to setup and maintain on a server. It just works. This means my little side project can remain a little side project, instead of become a burden with a bunch of unnecessary complexity that modern frameworks introduce.

Anytime a hello-work tutorial starts with running a command that generates 50 boilerplate folders/files, I die a little inside.
1 comments
trumpdong 7 days ago
What's your web server? To connect PHP with nginx you need a bunch of arcane configuration.
link
al_borland 7 days ago
I generally just use Apache. A classic LAMP setup, if a DB is needed for anything. If no DB is needed, I guess it’s just LAP

This is pretty quick and painless to setup. SLES had a single command for it back when I used it, if I remember correctly. I currently have a simple Ansible playbook for it on RHEL.

It’s certainly much more straightforward than deploying Flask to production, especially if just using the default document root and not getting into virtual hosts.

I thought about going to nginx once, but as I started looking into it, I had to stop myself and ask why, as Apache was more than adequate for what I was doing, I had no issues with it in the past, and the setup was dead simple. It would be change for the sake of change, and seemed more annoying to boot, to your point.

link
trumpdong 7 days ago
Do you have any concerns about performance? The original reason nginx displaced Apache was to replace a thread-per-request model with an epoll state-machine model. I think Apache now supports the latter, though? In the age of AI scraping, you probably don't want to be prematurely pessimizing.
link
al_borland 7 days ago
That’s not really an issue for me. I use this setup for small internal stuff. It might have 300 users at most, and they aren’t making constant requests. I run it on a small VM and only run into issues when someone dumps in so much data that PHP runs out of memory, which isn’t an Apache issue. And that memory issue doesn’t take down the site or server, it’s just the one request that dies. That used to happen maybe 5 times per year and was almost always due to user error (they screwed up something to end up with that much data in the first place). Some things changed and that particular tool is gone, so there should be no more issues with that.

I think a lot of people build everything assuming it will be the next Facebook, when it’s not. This leads to a lot of complexity in the name of potential future scale that never comes. For some, they are building the dream, but for an internal enterprise tool, mostly geared toward one team (which filtered out a little beyond into the org), I’m not worried about it.

The current setup has been running for 10 years now with minimal maintenance. Just moving it as needed to avoid EOL operating systems and platforms. For something that is a nice-to-have and never felt like a main deliverable for my job, this is ideal.

I almost rewrote it in python once, and planned to host that with nginx, but then I came to my senses.

link
thenthenthen 7 days ago
I loved php came bundled with OSX, you just run php -s portnumber (iirc) as and you have a php enabled webserver running locally, so fun for experiments and super convenient especially compared to nowadays… i would prolly use Python, so make venv, activate, etc etc.
link
al_borland 7 days ago
> you just run php -s portnumber

You can install PHP with homebrew or macports and still do this. I use it all the time.

https://www.php.net/manual/en/features.commandline.webserver...

link