3 ms·

This is nothing to do with PHP the language. You can have an HTTP server and templating engine in any scripting language. It’s just the way that PHP is distribu

This is nothing to do with PHP the language. You can have an HTTP server and templating engine in any scripting language. It’s just the way that PHP is distributed is particularly easy. Someone could throw together a “PHPython” from existing components and get the same effect.

nurettin 3y ago
Apache knows how to serve php, it is harder with python.
- creshal 3y ago
  mod_python was supposed to be that, it's a real shame it never got enough traction.
  - nurettin 2y ago
    Perhaps they should have gone for something more specific, like mod_jinja
KronisLV 3y ago
> Someone could throw together a “PHPython” from existing components and get the same effect. Python has been around for like 30 years, why isn't that quite the case? I guess there was mod_python but nobody cared enough: https://modpython.org/ https://modpython.org/ I guess there's now mod_wsgi which is similar to PHP-FPM in some ways: https://modwsgi.readthedocs.io/en/develop/ https://modwsgi.readthedocs.io/en/develop/ Yet, even with the actual deployment not being much different (just used Apache as an example here), there's still dependency management, which Python is often described to be pretty messy at, virtual environments or not. With PHP, most of the stuff you need for common use cases often is pre-installed and is just a matter of enabling some plugin in the config. That said, I deploy most of my stuff in containers, so PHP, Python, Node, .NET, Java and others all become more alike when viewed from the outside.
- mgaunard 3y ago
  Because this method of deployment is not only unsafe but also doesn't scale. In the age of cloud, you just run your web application as its own server, and just have a proxy that fronts it.
  - cess11 3y ago
    Some aren't going to fall into the clown age trap at all.
  - KronisLV 3y ago
    > Because this method of deployment is not only unsafe but also doesn't scale. How is a mainstream web server acting as a reverse proxy for an app server unsafe? You get the benefits of one common approach to configuration, request logging (and possibly log shipping), rate limiting, compression, path rewriting and so on, while letting the app server handle the actual app and language runtime stuff (whether it's some Python app server, PHP, Java with Tomcat or whatever). You can even serve any static assets right there, alongside your API. You can either include everything in a container, have separate containers for each process with overlay networking, or just have them run on the OS directly with only the web server binding to whatever ports you want to expose. As for scaling, none of that prevents you from running anywhere between 1 or a million instances in parallel, with some load balancing (whether it's multiple servers or containers across a cluster). If it's really that bad, throw in HAProxy or something into the mix, alongside whatever cache solution tickles your fancy. That's besides the point that I could provide a service to everyone in my country on a single rack (redundancy aside), not everyone even needs some mythical sky high scaling target. > In the age of cloud, you just run your web application as its own server, a just have a proxy that fronts it. Whether you use your own ingress (there's a lot of good ACME solutions out there) or something that your cloud provider gives you, using a server per app would in many cases be wasteful and there's a bunch of ways to increase the density, especially with the dynamic scheduling most container orchestrators could also give you.
    - mgaunard 3y ago
      mod_php runs in the same process as your http server, with the same rights. It's comically bad, especially in mutualized environments, and the reason why PHP is such a common target for hacks.
skywhopper 3y ago
Oh but if your web server had PHP installed, it really was “easy” in a way that modern web programming is not. Yes, you could replicate it with Python, but actually you can’t, because no one has “thrown together” a PHPython. Nothing today can beat the feeling of being able to just drop a .php file in a directory and have an interactive, dynamic web page up and running
lloeki 3y ago
> in any scripting language Scripting? Ha! We used to do CGI in C when Perl wasn't fast enough. <old-man-yells-at-cloud />
xigoi 3y ago
This is not even a hypothetical. CGI is right there.

nurettin 3y ago

Apache knows how to serve php, it is harder with python.

creshal 3y ago
mod_python was supposed to be that, it's a real shame it never got enough traction.
- nurettin 2y ago
  Perhaps they should have gone for something more specific, like mod_jinja

KronisLV 3y ago

> Someone could throw together a “PHPython” from existing components and get the same effect. Python has been around for like 30 years, why isn't that quite the case? I guess there was mod_python but nobody cared enough: https://modpython.org/ https://modpython.org/ I guess there's now mod_wsgi which is similar to PHP-FPM in some ways: https://modwsgi.readthedocs.io/en/develop/ https://modwsgi.readthedocs.io/en/develop/ Yet, even with the actual deployment not being much different (just used Apache as an example here), there's still dependency management, which Python is often described to be pretty messy at, virtual environments or not. With PHP, most of the stuff you need for common use cases often is pre-installed and is just a matter of enabling some plugin in the config. That said, I deploy most of my stuff in containers, so PHP, Python, Node, .NET, Java and others all become more alike when viewed from the outside.

mgaunard 3y ago
Because this method of deployment is not only unsafe but also doesn't scale. In the age of cloud, you just run your web application as its own server, and just have a proxy that fronts it.
- cess11 3y ago
  Some aren't going to fall into the clown age trap at all.
- KronisLV 3y ago
  > Because this method of deployment is not only unsafe but also doesn't scale. How is a mainstream web server acting as a reverse proxy for an app server unsafe? You get the benefits of one common approach to configuration, request logging (and possibly log shipping), rate limiting, compression, path rewriting and so on, while letting the app server handle the actual app and language runtime stuff (whether it's some Python app server, PHP, Java with Tomcat or whatever). You can even serve any static assets right there, alongside your API. You can either include everything in a container, have separate containers for each process with overlay networking, or just have them run on the OS directly with only the web server binding to whatever ports you want to expose. As for scaling, none of that prevents you from running anywhere between 1 or a million instances in parallel, with some load balancing (whether it's multiple servers or containers across a cluster). If it's really that bad, throw in HAProxy or something into the mix, alongside whatever cache solution tickles your fancy. That's besides the point that I could provide a service to everyone in my country on a single rack (redundancy aside), not everyone even needs some mythical sky high scaling target. > In the age of cloud, you just run your web application as its own server, a just have a proxy that fronts it. Whether you use your own ingress (there's a lot of good ACME solutions out there) or something that your cloud provider gives you, using a server per app would in many cases be wasteful and there's a bunch of ways to increase the density, especially with the dynamic scheduling most container orchestrators could also give you.
  - mgaunard 3y ago
    mod_php runs in the same process as your http server, with the same rights. It's comically bad, especially in mutualized environments, and the reason why PHP is such a common target for hacks.

skywhopper 3y ago

Oh but if your web server had PHP installed, it really was “easy” in a way that modern web programming is not. Yes, you could replicate it with Python, but actually you can’t, because no one has “thrown together” a PHPython. Nothing today can beat the feeling of being able to just drop a .php file in a directory and have an interactive, dynamic web page up and running

lloeki 3y ago

> in any scripting language Scripting? Ha! We used to do CGI in C when Perl wasn't fast enough. <old-man-yells-at-cloud />

xigoi 3y ago

This is not even a hypothetical. CGI is right there.