[KronisLV]

> 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]

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.

[KronisLV]

> mod_php runs in the same process as your http server, with the same rights.

mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.

Here's a very simple setup of two separate processes, with Supervisord (this is what runs in my self-contained dev container, but no reason why someone couldn't do something similar with systemd, or on a container cluster, with different users/permissions for each process):

  [supervisord]
  nodaemon=true
  [program:php-fpm]
  command=/usr/sbin/php-fpm -c /etc/php/fpm/php-fpm.conf --nodaemonize
  [program:apache2]
  command=/usr/sbin/apache2ctl -DFOREGROUND

And approx. how the Apache configuration might look:

  LoadModule proxy_fcgi_module "/usr/lib/apache2/modules/mod_proxy_fcgi.so"
  <FilesMatch \.(php|phar)$>
    SetHandler "proxy:fcgi://127.0.0.1:9000"
  </FilesMatch>

Conceptually, that's not very different from WSGI for Python: https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface#S...

But yeah, I agree about the shortcomings of mod_php.

[Izkata]

> mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.

  php -S localhost:8000

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

[mgaunard]

Or even simpler, just make your application listen to a particular port and implement a full HTTP server, and reverse proxy to that (or not) using whatever tech you fancy (Apache, nginx, Cloudflare, Cloudfront, ELB...)

This achieves the same thing while providing more control and layering standard protocols.