Not sure about the "ad" aspect. You are certainly right that there is a FastCGI-like aspect in Passenger, though I think there are more interesting aspects than just that.
There is a FastCGI-like aspect in the sense that it spins up a long-running server process and uses it to handle multiple requests. But this aspect is not very interesting: pretty much everything these days except for PHP and CGI work this way.
FastCGI also specifies a protocol for communication between the FastCGI server and the backend server. Passenger supports plain HTTP for communication between itself and the backend.
So I think comparing it with FastCGI is a fine way to look at it, but I think there is an even better way. And that is to see Passenger is to see it as (1) an application server and (2) an application management platform. Passenger's goal is to improve performance, security, and developer and operational productivity.
What does that mean? It achieves these goals through process management and supervision; by integrating with Nginx so that it can provide a layer of I/O security, so that you don't have to setup reverse proxies, and so that it can accelerate static asset serving; by acting as a reverse proxy so that it collect and report statistics and analytics to the administrator at the HTTP and process level; and by providing administration tools. In a post-Docker world, Passenger (in the near future) aims to fill the missing parts between the container and the application, by running it inside the container in front of your app and providing log management, zombie process handling, multi-CPU scaling for Ruby/Python/Node apps, debugging tools, etc. All this while staying small, flexible and composable so that you can integrate it with other tooling.
[+] [-] Animats|9 years ago|reply
[+] [-] FooBarWidget|9 years ago|reply
There is a FastCGI-like aspect in the sense that it spins up a long-running server process and uses it to handle multiple requests. But this aspect is not very interesting: pretty much everything these days except for PHP and CGI work this way.
FastCGI also specifies a protocol for communication between the FastCGI server and the backend server. Passenger supports plain HTTP for communication between itself and the backend.
So I think comparing it with FastCGI is a fine way to look at it, but I think there is an even better way. And that is to see Passenger is to see it as (1) an application server and (2) an application management platform. Passenger's goal is to improve performance, security, and developer and operational productivity.
What does that mean? It achieves these goals through process management and supervision; by integrating with Nginx so that it can provide a layer of I/O security, so that you don't have to setup reverse proxies, and so that it can accelerate static asset serving; by acting as a reverse proxy so that it collect and report statistics and analytics to the administrator at the HTTP and process level; and by providing administration tools. In a post-Docker world, Passenger (in the near future) aims to fill the missing parts between the container and the application, by running it inside the container in front of your app and providing log management, zombie process handling, multi-CPU scaling for Ruby/Python/Node apps, debugging tools, etc. All this while staying small, flexible and composable so that you can integrate it with other tooling.
Disclaimer: I am a Passenger developer.