Catalyst 5.9: (Less Code, More Plack!)

When I was introduced to Catalyst during the version 5.7 days, one of its features that really clicked with me was how it isolates your application code from the web server.  I can’t be certain that Catalyst was the first major Perl framework to take this approach, but it clearly was responsible for helping to popularize the idea.   It is an approach, which has over time gained many admirers (and imitators J)

 

Prior to Catalyst I only knew two models for web development, CGI and mod_perl.  Although both technologies have individual pros and cons one significant problem both share is the fact that you needed a full power web server (Apache), to run your code.  Additionally your code tended to be tightly bound to this environment.  This development model suffers from a lot of up-front effort to set up, configure and run.  To make matters worse this effort inevitable varied from OS to OS (think about the different between setting up Apache on Debian versus Redhat, for example).   Additionally, the single server model of development leads to a lot of trouble as we scale teams in size since developers are often overwriting each others code when there is only one directory where the running code can live.  Typical workarounds involved setting up complicated configurations of virtual hosts per developer and a lot of legwork each time new programmers rolled onto and off of a team.

 

With Catalyst your application code is neatly isolated by the Catalyst::Engine interface.  Basically Catalyst::Engine defined the basics of how to hook up an application to a back end server capable of listening to web traffic and responding.  To get us started Catalyst came with a number of Engine subclasses for the more common needs, including the ability to run your server locally, as a fast-cgi process or in a testing mode.

 

The ability to let each developer run his or her own webserver with minimal upfront configuration effort was truly eye opening moment for me.  Basically you could check out code and just run the application.  This dramatically lowered the barrier to contribution.  It also made teaching Perl for web development much easier.  You could simple run the Catalyst project helper script and get started.  You even get great local logging (no more hunting for where Apache is spewing its logs, which is a big hassle if you’ve ever been a consultant bouncing from project to project and everyone has a slightly different take on where the logs should go).  And you could start, stop and restart your server easily.

 

This concept of being able to cleanly separate your application logic from how you need to run the application on a web server is so monumentally useful that it seems obvious in retrospect that eventually someone would refactor and generalize the concept.  Indeed, other programming languages, such as Python (WSGI) and Ruby (Rack), showed the dynamic programming language world great leadership with this idea.  Although there is more than one attempt in CPAN, the project that really succeeds in bringing the idea to general usefulness for the Perl community is the PSGI specification and its canonical implementation, Plack.

 

Unless you’ve been legally dead for tax purposes the last year or so, you would be aware that Plack has truly taken the Perl world by storm (as the saying goes).  It is rare in our anarchistic meritocracy that one project can be so universally lauded as the dominant right way to do it.  Plack applications and reusable Middleware forms a clear core for web developers and a strong basis upon which all types of web frameworks can share common needs and solve common problems.  And PSGI’s conceptual similarity to similar specifications from Python and Ruby means that we can leverage some of their groundwork learning to jumpstart the Plack ecosystem.

 

For Catalyst developers, Plack is great news, since it helps us reuse code across applications when the full power of Catalyst is not desired.  It also means that middleware components developed for Plack by non-Catalyst web developers can be used to speed Catalyst projects.  For example, many Catalyst programmers prefer to use Plack::Middleware::Static over the Catalyst Static Plugin, since the Plack middleware is more generally usable outside of Catalyst.  Why not use and contribute to something that everyone building web apps can also use, not just those developing with Catalyst?  Even though I am a Catalyst programmer there are times when I just don’t need all that power with the entire overhead that comes with it.  Greater sharing means better code and less repetition across web frameworks.

 

Catalyst::Engine::PSGI brought Catalyst to Plack, but those of us who are Catalyst developers started to wonder if there might be a better approach.  Why bolt Plack onto Catalyst, why not just use Plack natively in Catalyst? That way we’d be able to totally drop everything under Catalyst::Engine (and save us the maintenance work as well as take advantage of a larger contributor community.)  Such a large move is not totally without precedent; we did port Catalyst to Moose a few years back, and managed to do while preserving backward compatibility.  Although there’d be a lot of work, the ‘long tail’ benefits would greatly outweigh this initial outlay in development.  In fact, such a big move would really benefit and reaffirm Catalyst’s standing as a cutting edge web framework, despite being 6 years old!

 

Catalyst 5.9 is the result of this idea.  Although it took a long time to achieve, I believe the core team’s commitment to making sure this massive under the hood change would be as widely compatible with existing production applications should be greatly appreciated.  Achieving that backward compatibility was non trivial but in the end essential to drive adoption.  Completing this project is great news for Catalyst since it means there’s now a huge chunk of code we no longer have to maintain under the Catalyst namespace.  Instead we can take advantage of the concerted community effort of web developers using Plack, from other popular frameworks such as Mojolicious and Dancer, to people choosing to roll their own on top of the basics that Plack gives you.  I feel certain that having the whole community working together on some of the core bits to hook your application to all the various types of deployments (from Apache to Nginx) is of great benefit.  This way instead of everyone writing his or her own common bits (and repeating all the learning and painstaking error testing) we could share them across all Perl web development.

 

This is also good for Plack because all new Catalyst projects (as well as people upgrading from older Catalyst versions) will automatically become part of the Plack community, which hopefully will increase interest and contributions to Plack.  Catalyst is a very popular development framework for Perl, with multiple published books and a vast software ecosystem, all of which vaults it to the top of the list for any company serious about writing a Modern Perl website.  In addition, there a quite a few high volume, heavy load Catalyst web sites out there, and I will be very excited to see Plack pick up that traffic!  I also anticipate that as Catalyst programmers learn to live with Plack better we will see more of the Catalyst specific code migrate to Plack middleware.  Finally, it is good for the Perl community as a whole, since I believe Plack is a paradigm shifting event for Modern Perl and anything that spreads Plack around is inevitable good for us.

 

There’s never been a better time to be a Catalyst Developer, in my humble opinion.  With Plack as a core technology for Catalyst, it will be even easier to deploy to some of the new Platform as a Service providers (such as Dotcloud and Stackato) as well as take advantage of all the great code, ideas and miscellaneous contributions coming out of the Plack community.  Additionally, I hope that Catalyst developers, particularly plugin developers, can start to take a long look at some of our Catalyst specific code and migrate to (or contribute) Plack Middleware.  For example, I imagine at some point we’d migrate the Catalyst Sessioning and Authentication code to leverage existing Plack Middleware equivalents.  Imagine seamless session information shared across Catalyst, Dancer and Mojolicious!  I believe this newfound ability to share will invigorate and renew some of the more important parts of the Catalyst ecosystem.

 

As time goes by and we learn how to better synchronize Catalyst and Plack I am sure this will only get better.  Long live DRY!

 

More Information:

 

Find the most recent, stable Catalyst.

Catalyst Project Homepage.

Buy the Catalyst book.

For Developers, you probably also want the Catalyst Manual and the Catalyst Developer Tools.

Lastly, Task::Catalyst contains a list of highly recommended parts of the Catalyst software ecosystem.

Ah, and if you are just starting to learn Perl you might want to start here!

 

 

Comments

[machine a sous en ligne]

J'ai trouvé un si grand nombre de s'engager trucs dans votre journal web en particulier son dialogue. Je spécule, je ne suis pas au singulier celui ayant toutes les dernières traces du bonheur ici suivre le travail exceptionnel.

[Gregory Schieffer]

This is a lot of detail for a newbie like me to understand. You are definitly a good source of information and I'll be back to learn more. Thank you for the effort you certainly put forward in passing information on to newbies like me.

[Electrician Indiana]

Do this means I can re-run the scripts for example to see if newer versions of Catalyst or its plugins generate different code, or to see how I may have changed the generated code?

[john]

You can rerun the catalyst.pl script and force update the generated code to upgrade it.