The first thing to understand about Plack is that it is a pure Perl HTTP server which completely replaces your existing server such as Apache.

Strictly speaking, that statement is not quite true ... that is to say, there might be a better way to say it.   If I may now brashly presume to try.

Plack is a sort of “software ball-and-socket joint” that allows your web application to run in a variety of possible environments, under many different web-servers including the plackup command-line “server,” without being dependent on any one of them.   It allows you to “un-wedge” your application from any server-specific dependencies that it might now have.   To completely butcher my analogy, “if you will make your app compatible with the Plack ‘ball,’ then you become free to choose the pre-existing ‘socket(s)’ of your choice.”   (I am making no reference to TCP/IP “sockets” here ...)

I recently used Plack to redeploy a crufty old mod_perl application into FastCGI.   (You can read all about my troubles and whining and inevitable stumbling-around here on Perlmonks.)   To accomplish this, I built a new Plack-compatible entry point into the application which in turn called the legacy handler() routine, giving that handler a new parameter-object which was sufficiently compatible with what the legacy application expected. I also had to wedge-out and replace a few calls to Apache-specific API routines.   Direct calls to handler() no longer take place.   I built an app.psgi file that would invoke that routine (because that is what plackup looks for).

“Okay, that’s the ball ... now, let’s build the socket.”   I prepared an off-the-shelf package that could be called by FastCGI, and I chose to arrange for it to look for app.psgi in the same way that plackup does.   Now, the application can easily be invoked either by FastCGI or by the plackup command, and/or by any other environment that we may one day select and prepare a “socket” for, and it never has to know the difference.   (Although it is capable of doing so, and for developer convenience it actually does.)

Plans are now afoot to have portions of the app running under the nginix server “over here” while it is also running under Apache (through mod_fastcgi) “over there,” and no further application changes will be required to accomplish that.   We are also planning to use the Plack infrastructure to allow front-end application servers to converse separately with back-end servers ... exchanging information across CPU boundaries using convenient existing code that we know already works well.

It is also worth noting that the concept of Plack isn’t new, nor is it unique to Perl.   Python actually did it first.   Ruby has “rack.”   It just happens to be a very good idea.   Plack is fast, efficient, well thought out, and well implemented.