Why PSGI/Plack Matters (Testing)

| 4 Comments

Plack is one of the most important projects in the Perl world in the last two years. It's a good idea borrowed from Python's WSGI and Ruby's Rack but made Perlish; it's a simple formalizing of a pattern of web application development, where the entry point into the application is a function reference and the exit point is a tuple of header information and a response body.

That's it. That's as simple as it can be, and that simplicity deceives a lot of people who want to learn it.

Test::WWW::Mechanize::PSGI is one of many reasons why it matters.

Given a Plack application, you don't have to deploy to a web server—even locally—to test your application as if it were deployed. TWMP executes your application as if it were running via Plack (because it is!) and allows you to perform Test::WWW::Mechanize tests against it.

Certainly you need to test that you've deployed your application correctly when you do deploy it, but that's a single test.

Plack and TWMP (and Plack::Test) use the well-defined Plack pattern to make something which was previously difficult into something amazingly easy. They're not the first and they won't be the last, but they do demonstrate the value of Plack.

4 Comments

Plack is a hard sell. The documentation goes to great lengths to tell us why we need it, but it shows little information on how we implement it. It doesn't have the clear use case like perlbal, or memcached, or fastcgi - in fact it plays nicely with all those technologies.

I'd really like someone to explain Plack clearly, "formalizing of a pattern of web application development" does not make it self evident I have to have Plack. (Although I do use it with Web::Simple.)

The documentation goes to great lengths to tell us why we need it, but it shows little information on how we implement it.

Because that's what it is - unless you're a web framework developer, you don't need to know how you implement it, since most frameworks supporting PSGI do that already for you.

(Although I do use it with Web::Simple.)

So, I'm very glad to see this :)

It doesn't have the clear use case like perlbal, or memcached, or fastcgi - in fact it plays nicely with all those technologies.

This topic has been discussed a lot, and I've submitted my talk to cover this for this year's conferences, including YAPC::NA and OSCON.

I'd really like someone to explain Plack clearly, "formalizing of a pattern of web application development" does not make it self evident I have to have Plack.

Just in case you haven't looked, i've got a lot of slides up on slideshare talking about Plack and PSGI: The one from OSCON 2010 is the latest we have, and Plack website has more links to blog posts and presentations.

When writing web app you usually don't use Plack/PSGI directly, but a web (micro)framework that supports PSGI. PSGI support in a framework means that you can deploy it using any server that supports PSGI / has PSGI wrapper: CGI, FastCGI, mod_perl, mod_psgi, HTTP::Server::Simple; and that you can use 'plackup' utility for running, and Test::Plack / Test::WWW::Mechanize::PSGI for testing.

Using PSGI-capable web framework usually means that you can use many Plack middlewares, e.g. easily adding output caching, or ETag, etc.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on March 18, 2011 9:55 AM.

On Encapsulation was the previous entry in this blog.

What Perl Could Learn from Java WARs is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?