Monks,

In developing Perl web applications, we've all seen the same problems and/or anti-patterns arise again and again. Here I will point some of them out and hope for thoughts on possible solutions.

Too Many Options

I argue that Perl suffers from "Too much of a good thing." How many web development frameworks are there? Which one of the 196 Config:: systems should we use? Which database ORM should we use? Do we use mod_perl or FastCGI? Which email module is best for this project? How should we trap errors? Which MVC model should we use?

Certainly each option is a good solution for a specific kind of situation, but how do we know *which* module works for *this* solution?

Which toolset?

Do we use DBIx::Class + Catalyst, Class::DBI + HTML::Mason or straight DBI + CGI::Application? Should I write HTML widgets myself or use CGI, HTML::Widget, HTML::DOM or HTML::TurboForm? And above all, Which ones work together better?

I would rather have the options than not have the options, but it would be great if we could get some good documentation together that would detail how to build a web application using DBIx::Class, mod_perl and Catalyst, vs using HTML::Mason, FastCGI and Rose::DB::Object (just contrived examples of options, nothing more).

How to Scale Out?

If the web application is successful you will need to plan ahead for scaling. Scaling out without session-affinity (i.e. "shared-nothing") is arguably the more popular option because of cost (an additional web server is cheaper than an F5 Networks BigIP). However scaling out means sharing Session and Application state. It means managing more than one server. It means you need to be capable of deploying updates to all servers in a way that won't cause errors, undesirable behavior or downtime. In any case, it means much more than just setting up another server behind a load-balancer.

Development Sandboxes

While one programmer can handle dealing with the Dev->QA->Prod push just fine (in most cases), 2 developers or more can really cause problems. Since mod_perl generally means restarting Apache httpd each time a code change has been made, you may end up running a local version of the code (and possibly the database). Having a local version implies that you are using CVS, SVN or some other revision control system (yes, another set of options with no clearly-defined winner).

The total lack of a dead-simple IDE (like Visual Studio) means that we get different people using different tools. Again - another set of options with no clearly-defined winner (even though we all have our favorites). On the other hand, the ability to use whichever editor we want without relying on the IDE to generate code, line up dependencies or compile the project gives us the flexibility we have come to expect.

Switching from a Windows desktop to Linux (i.e. Ubuntu) saved me a great deal of pain, but it was a trade-off. Is there a Gnome equivalent to the super-simple Tortoise-SVN shell extension for Windows? Right-click->SVN->Update doesn't get any easier.

Which Dev—»QA—»Production Publishing Toolset?

Once you have made progress on your app and it's time to publish, you have more options:

• RCS Checkout on QA and Production
• FTP or rsync to QA and Production
• Make a PAR::Dist
• Use App::Build (though docs and examples need work).
• Use App::Install (though docs and examples need work).

Each of these options will need to account for configuration files and other differences between Dev, QA and Production.

Maintenance

Thus spake the master programmer:
``Though a program be but three lines long, someday it will have to be maintained.''

While writing a test suite for a single module is an exercise in quality and partial proof of the author's will to produce something of real value, we tend to think nothing of releasing a mission-critical web application without a single test. Not even one. Perhaps the reason is that until Catalyst or Apache2::ASP it was very difficult to write unit tests for web applications because, well, you had to execute them from within a webserver, and it was just a huge pain.

Having developed my last several projects on Apache2::ASP with full test suites built with Test::More et al, I can attest to the value of code-coverage (via Devel::Cover), profiling (via Devel::NYTProf) and regression-awareness with regard to web applications. Instead of wasting time clicking through the website (i.e. a 12-page loan application) entering every possible value, testing every possible input error, etc. I could just run the test suite in seconds or minutes and check to see if any of those bugs I was testing for had shown up.

If only I had web application test suites in the past. It would have saved countless hours and allowed me to add the features we really could have used, but didn't have time for. I could have done that refactoring without worry that application behavior had changed somehow.

Looking Ahead

The problems we face right now are Good Problems to Have. We have several options to choose from and there is a great deal of work happening in the areas I've pointed out above. I expect that the more people we have working on these problems, the more solutions we will end up with (yes, more options too).

With enough time and entropy the winners will reveal themselves. Until then, we can make our own choices.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.