I've been programming on Perl for a long time, I've always used CGI technology to build my applications. Now I think to rebuild them and write new ones on FCGI. Please, explain the difference between unsing FastCGI and PSGI with f.e. Starman. Also I'm asking to explain what Perl frameworks (which use FCGI) are "in trend" today? I understood that I can force my CGI scripts to work as FCGI scripts using CGI::Fast. Are there any other modules to do this?
Thank you!
On
It is important to understand that CGI is a standard definition of how an information server passes data to a separate program.
The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported
information servers are HTTP servers.The interface has been in use by the World-Wide Web since 1993. This specification defines the interface known as `CGI/1.1', and its use
on the Unix(R) and AmigaDOS(tm) systems.
In the standard model, the web server starts the external program each time it needs one, marshals the data into the standard format and passes it to the program [either as part of the environment, or via the external program's Standard input, depending on the HTTP Method (GET, POST, etc.) used. The program processes the data, returns it's data by printing headers and content to Standard Output, and then exits.
The main drawback to CGI has always been the expense of starting the external program on each invocation. On Unix, this requires the web server to create a copy of itself in memory (fork), and then have the external program overlayed on the copy (exec). The fork/exec cycle is computationally expensive, especially when you're talking about a large Apache process (multi-MB memory footprint) overlayed with a Perl interpreter, which then needs to parse the Perl program before it can be run.
In order to remove the fork/exec cycle from the equation, a couple of new things were developed. Mod_perl embeds the Perl interpreter into the apache process, removing the need to fork/exec on each invocation, and also allowed for caching of parsed perl programs. Numbers reported by various organizations put the increase in throughput at anywhere form 20 to 100 times more than CGI.
A second method, called FastCGI was also developed around the same time. In FastCGI, an external program (often a container, or an application server) is started at the same time that the http server is started, and the http server proxies requests to the FastCGI process. This model provides the same benefits of removing the fork/exec cycle, and has a set of pros/cons that are different from mod_perl.
In the end, CGI/FastCGI/mod_perl, whichever you chose, your program had to understand how to get at the data passed to it by the web server, and that's the crux of the matter, nearly every post-CGI technology defines it's own way of passing data to/from the program (the GI in PSGI still stanbds for Gateway interface), but provides an adapter to convert it's preferred way, to the CGI model, to help make adoption easier.
I'm not sure if I've answered your question at all, but thanks for asking it. I enjoyed writing this answer ;-)
You're looking at this from the wrong perspective. Don't think about how you are going to deploy the program. Instead, write your program to the PSGI interface. Then you'll be able to deploy your application in any environment - CGI, FastCGI, mod_perl, etc. without having to change anything.
You can write "raw" PGSI using modules like Plack::Request and Plack::Response, but you'd be better advised to use a framework like Dancer or Catalyst.
If you have existing CGI programs that you want to run in a PSGI environment, then see Plack::App::WrapCGI.