moof1138 has asked for the wisdom of the Perl Monks concerning the following question:

I do a fair amount of Perl work in a lot of domains, but for web stuff things fall roughly into two classes: fairly simple template based DB driven web apps that run on mod_perl, and use to get params/cookies/etc., set headers/cookies/etc, and return the HTML. Then there are generally simpler tools that handle XMLHttpRequest again using to get params/cookies/etc. and return results in JSON. We use a lot of our own modules (along with blessed, lovely CPAN) to handle keeping things fairly cleanly separated into their proper domains, and adhere to MVC, so the actual cgi bits are pretty small and simple. (Side note - Catalyst seemed a bit heavy weight to me in the past, but I've been working on making some new things in Catalyst, since I see it it can take some of the work off our hands, and it seems like there really is some gain there.)

Things currently work well, are easy to read, and are easy to maintain. I've been reading posts from folks on various sites discussing how great Plack is off and on for a while now, so I've been looking into it. I looked over the PSGI FAQ which took a crack at explaining this very question, and I think that since we only have a few folks in our org who work on these things, they are never going open source, and will always be able to run on servers we control, that Plack it not really something I need to worry about for my current purposes (which obviously might change if deployment goals change), but I wanted to just throw it out there to see if there was some benefit for my current kind of deployment I might be missing.

Replies are listed 'Best First'.
Re: Understanding benefits of Plack
by Corion (Patriarch) on May 07, 2011 at 15:52 UTC

    Plack (and PSGI) is nice in the sense that you don't need to worry (that much) anymore about whether your script will be running under mod_perl or as CGI, or via HTTP::Server::Simple, and you still get to do fancy stuff like providing the page content through a callback. I found Plack nice when writing a webserver that did background page fetching through AnyEvent - I didn't have to look at how AnyEvent::HTTP does its thing but could simply use Dancer, which respects PSGI. In the end, I used Twiggy as the backend HTTP server.

Re: Understanding benefits of Plack
by chromatic (Archbishop) on May 07, 2011 at 17:45 UTC

    I appreciate the separation of concerns that Plack provides. It's easy to add debugging middleware or static serving middleware or authentication middleware or logging middleware without modifying the application itself.

Re: Understanding benefits of Plack
by unlinker (Monk) on May 08, 2011 at 12:07 UTC

    While I do not understand Plack/PSGI completely, let me risk a response in the hope that I will be corrected: PSGI is a specification for Perl applications to work with a variety of Webservers. In other words, if you write your application in a manner consistent with PSGI, then you will enjoy the benefit of running your application in a whole variety of Web Server Infrastructures

    Technically, if you are an application developer, (as opposed to somebody who creates web frameworks for app developers) you dont really have to deal with or understand Plack. This is the stated belief of Plack/PSGI's main creator Miyagawa. On the other hand, if you are a framework creator/writer, then you need to understand PSGI and write your framework consistent with it.

    As app developers, all we need to do is to choose a framework that plays with PSGI: There are legacy frameworks (BP - Before Plack) like CGI::Application that provide a "driver" that talks PSGI and there are modern frameworks (AP?) that are built with PSGI from ground up like Dancer. All we application developers need to do really is to choose the right framework that suits us and do what we do best. Create great perl apps!

    You can however write your application that bypasses the framework layer and talks PSGI directly. Much like you are currently doing with mod_perl — use mod_perl calls to create the web environment in which your application runs. But if you were to distrubute such an application, your potential users will have to do much before the app can be run.

    In the age of BP, deploying solid perl web applications was significantly harder than say deploying PHP applications. AP, however, has taken perl applications far far ahead of PHP at least as far as ease of deployment is concerned. In some cases, all it takes is to say "./" and your web app is ready. That to me is the greatest benefit of Plack

Re: Understanding benefits of Plack
by sundialsvc4 (Abbot) on May 09, 2011 at 15:05 UTC

    Deployment can be a time-wasting issue for a web application, and arranging your system “to be easily compatible with Plack” is a way to save a lot of that time, if it works for you and your application.

    Changing the method of deployment is, traditionally, an even more tricky thing to do, coming as it usually does when the app has become a “legacy system.”   Once again, this might make things easier.   The app code that you write becomes more platform-agnostic, with the actual set of necessary changes being concentrated into a much smaller place.