Hacker News Reader

Comment by samsquire | Hacker News Reader

PHP solves so many problems to do with deployments and scalability automatically.

- You don't need to explicitly install your replacement code and start that server (java -jar .... / node server.js )

- You don't need a systemd unit to keep your server running ( you can deploy as many PHP files as you like and they'll all be "running" )

- You don't have to worry about keeping your server up (the php file).

- You don't need to use Docker because PHP is pretty stable target.

- You're not forced to deploy Kubernetes or Docker swarm to deploy code infront of users.

- You could use Ansible to deploy your PHP but you can probably just use git.

- You can spin up multiple servers and deploy the same file to them all and nginx and php-fpm shall handle concurrency and parallelism for you since each PHP session is independent and stateless.

View on HN

> You don't need to explicitly install your replacement code and start that server

This is a double-edged sword though. Let's say I have a PHP file that "include"s another one and a request arrives in the middle of such a deployment where the first PHP file has been replaced but the second has yet to be - you now have undefined behavior.

Filesystem-based URL routing is one of the "features" I hate the most in PHP as it leads to countless security issues - simply uploading a file in the wrong place (or sometimes merely with a wrong extension) immediately turns into an RCE.

That's why you do symlink-based deployments with PHP. It works just fine and is also not a problem unique to PHP.

PHP itself doesn't follow filesystem-based routing, your webserver config does. PHP just executes what th webserver tells it to. Most PHP applications written in the last 10 years use a single entry point and are no longer prone to the attacks you are describing.

Yes it's true that proper config can make this problem go away, but the fact that some of the advantages of PHP such as ease of deployment (drop a .php file -> you have a webapp) is a double-edged sword as it encourages a lot of bad practices (that large legacy projects such as Wordpress continue promoting).

It's indeed possible (and quite pleasant) to do proper PHP with a good framework, sane web server config & modern development practices. The problem is that a sizeable chunk of the PHP ecosystem (and very popular projects such as Wordpress) are not doing that.

This. I love php, and especially Laravel. But the Wordpress community continues in the Stone Age of the development practices.

> - You don't need to use Docker because PHP is pretty stable target.

Not sure I agree with this. Upgrading PHP versions or managing extensions can be _sometimes_ a PITA, using Docker makes it easier. but for simpler apps, sure, apt install php and a few extensions, and you are good to go.

OTOH - a bit off though - I still haven't figured out how to properly build a php stack with Docker. Do I add an nginx instance to each app image? Or should the app container expose only the FPM? If I'd have to do it nowadays, I'd probably go with the second.

here is an example, https://github.com/visualex/docker-boilerplate-nginx-apache-... not using FPM but Apache, but you can see how nginx fits into the picture, you would be doing something like a fastcgi_pass testsite:9000; using the names in the referenced repo.

> You don't need a systemd unit to keep your server running

You do, actually. You need a systemd unit to keep your apache / nginx + fpm / whatever server that is actually handling and processing your requests.

Edit:

> You could use Ansible to deploy your PHP but you can probably just use git.

I wanted to emphasise the easiness of PHP in my comment.

You don't need a systemd unit file for your php files whereas you do for your Java app unless you're using a Java container such as Tomcat.

I have typically used system packages to install PHP and nginx and fpm which includes those systemd units

My overreaching point was the ease of using PHP. As a low tech solution.

In the previous era you just FTP your files to the server but you can use git instead which is probably easier than using Ansible. (That's my comparison of FTP vs Git vs Ansible and which is easiest)

Doing zero downtime deployments with PHP is easier than Java (rolling deploys in Kubernetes)

A bunch of these seem like either non-problems with other languages (what language forces you to use kubernetes?), or just “I’m at small scale and therefore don’t need to solve problems that come with large scale”.

> You don't need to explicitly install your replacement code and start that server (java -jar .... / node server.js )

If you just copy your code without explicitly flushing opcache, or having traffic on that server that you are copying your code to, that can lead some interesting issues where your old and new code pieces running simultaniuosly

> You don't need a systemd unit to keep your server running

Actually a systemd unit keeps your PHP-FPM processes running on most of the Linux distributions. But writing a systemd unit config file is like 10 lines

> You don't have to worry about keeping your server up

This is redundant with the point above.

> You don't need to use Docker because PHP is pretty stable target.

First, you don’t need Docker for other languages. Actually a static linked binary (for example Go) is much more portable than a PHP application. Secondly, good luck for keeping your OS up to date.

> You're not forced to deploy Kubernetes or Docker swarm to deploy code infront of users.

You are not forced to do this with any other languages. I was running Java, Node.js, Python, Ruby, Go applications without any of these (in large scale).

> You could use Ansible to deploy your PHP but you can probably just use git.

You can do this with any other language.

> You can spin up multiple servers and deploy the same file to them all and nginx and php-fpm shall handle concurrency and parallelism for you since each PHP session is independent and stateless.

Haha, thats a good joke. Once we ran into a PHP-FPM issue where separate FPM pools were running each others (separate) codebase randomly. And there are sessions, local files and opcache that are all stateful. PHP won’t help you writing safely scalable code at all. That’s up to the developers, regardless of the programming language. Oh, and PHP-FPM has nothing to do with handling concurrency.

Nginx and php-fpm (and the started php pool processes) together provides simultaneous parallelism and concurrency because each web client can do (edit: multiple) independent things at the same time.

It’s clear that you have no idea what’s the difference between concurrency and parallelism.

Actually in what concerns Java you don't need to restart anything beyond upload a new WAR file, hardly much different than uploading a bunch of PHP files.

You also don't need docker, application servers were docker before docker was an idea.

You certainly do need to keep Apache or ngix up.

I remembered reading and loosely following OSGI model in Java land and used Tomcat and forgot about WAR files.

I like that Erlang programs are robust and even if a program crashes, the BEAM runtime won't take the BEAM process out.

PHP programs don't tend to cause the nginx or php-fpm to crash but just the particular interpretation PHP instance which is replaced with a replacement restarted automatically.

Reply on news.ycombinator.com