The specification is PSGI, the implementation is Plack, and it's well documented here: PSGI/Plack. Note that the tagline on that page is, "Superglue interface between perl web application frameworks and web servers, just like Perl is the duct tape of the internet."

While most one-sentence summaries fail to tell the whole story, you can take from this one that Plack is a middleware that sits between the webserver and the application, and that often the application is a framework that hooks its back-end into Plack, and provides a platform for a higher-level application. It's possible to write an application from scratch that interfaces directly with Plack, but it's usually easier to sit a framework on top of it. However, you can comfort your one-track mind in knowing that it is possible to program an application to directly sit on Plack.

I doubt there's any better source of information than that page and the links it provides. But you can also talk to people on the IRC channel, as referenced at the bottom of the link provided in this post.

Pretty much everyone goes through this with Plack. This is a great primer: I finally get PSGI and Plack!

Almost everything here is interesting and inspiring: Plack calendar. One amazing thing worth noticing right away is the ability to run multiple applications under a single server while (potentially) sharing sessions and all kinds of other middleware goodies: Plack::Builder and Mounting Apps with Plack.

It is Awesomeness™ ... and here’s (I think) why.

For the past five months I’ve been dealing with a legacy application that was “wedged into” the Apache server by means of mod_perl.   This made perfect sense in 1998 or so when this system was first put on the drawing board, but it does not make sense now.   Plack enabled me to retrofit the application, with only a small number of very targeted changes, to run in FastCGI.   Or, in any and every other deployment alternative that Plack supports.

Plack is like a mechanical “slip joint” for web applications.   Plack provides a series of server-specific interfaces, all of which support a single, server-independent API.   By writing your application in this way, you are able to switch it to many different deployment strategies without re-writing it.

It certainly is convenient that one of those “deployment strategies” is the command-line plackup command.   This runs the app on your command-line, and yet your app cannot (unless it wants to...) see the difference.   (plackup is “just another Plack-compatible interface.”)

So here's something that I've been meaning to clarify for myself.

If I write an application for Mojolicious, which itself supports CGI, FastCGI, a Mojolicious-bundled server, and Plack, and I deploy the application with FastCGI, is there any benefit to pulling back and redeploying it on top of Plack? My understanding of the Mojolicious framework is that it should just work, regardless of the back end, as long as the back end happens to be based on either CGI, FastCGI, or Plack.

I understand that if I were to move to a different environment not supported directly by my framework Plack would be beneficial, as it supports a greater variety of servers and back-ends. But it seems to me it's one of those things that's available when I need it, and as long as I stick to a framework that supports it I can always migrate when I do need it.

Is this reasonable?




Dave

Is this reasonable?

Yes, it is reasonable.

Or to put it another way ... when creating a new web app, you should not use a low-level API like CGI, FastCGI or mod_perl. Instead you should either use a framework (Catalyst, Dancer, Mojolicious etc) or for very small projects, code to the PSGI API instead.

Where would a wayward unteachable unmentorable scallywag like me then therefore find out how this "plack" works from such a perspective?

Why would such a person, with no concept of or interest in the internet, care?

I use Plack/PSGI (ok, plackup and Plack::Request if we're being specific) when I want a tool to be persistent and to be available via http - but not necessarily running under my Apache httpd server.

Do you mind if I ask why not under apache?

Do you mind if I ask why not under apache?

One example is a job queue server. Because you could run into a race condition where two simultaneous requests to the server fetch the same job from the queue, one solution is to have a single process server responding to requests for new jobs. Because there is only one process listening, you can guarantee that once a job is assigned to one client it will not be assigned to any other clients.

If the job queue server ran under Apache, it might be more difficult to lock and synchronize the job queue while a job is assigned to a client requesting a job, because of Apache's multi-process/thread model.

Another example is a wrapper to a program which can only handle one request at a time - like skype's dbus api. I used a Plack/PSGI app to host the code that actually makes the skype dbus api call. I don't expect the application to get *that* much load, but forcing everything through a single thread of execution in this case worked for me.

NOTE: In the above examples I'm using plackup which allows me to run everything inside a single process. Starman for example is another PSGI server which is high performance and will let you run in a multi-thread/process model like you get with Apache httpd. Having the ability to choose between execution styles is very powerful - especially when it requires absolutely no change to your own code.

Another reason to handle some jobs in an out-of-apache process (yet persistent) is for performance. Say I have to use some memory hog module or read in large files which causes my memory footprint to grow. I can't really do that in all of my apache processes because I might run out of RAM. Using a PSGI server like plackup or starman to host the memory hog in a persistent environment will give you better performance than executing the same code from a system(...) call, and you can also play with the maximum number of running threads your memory hog can use, further preventing memory problems. If I had to run everything in my Apache httpd processes I might quickly run out of RAM on web applications which deal with video encoding for example.

Also if you find yourself in need of deploying updates to your code, a PSGI-based application which allows you to execute a few commands (handle the upload of new files, extract them into place, restart apache, etc) simply could not be done from within Apache. Not reliably anyway.

Here is an example of such a simplistic standalone app: Re: Networking Perl — and some commentary/discussion: Need Help in Understanding Some Code - Map and Scalar Questions.

When you run something like that with an engine like Starman (or Twiggy or plackup or…) you get a hot-restartable, hot-worker-assignable, little speed-demon with a tiny footprint that can be tested easily. Apache is deep and venerable but there are many ways to skin the HTTP cat. Many app developers today deploy on nginx or lighttpd instead for example. They do not have the feature bag apache does but they outperform it handily on several levels in simple webservice.