From mod_perl/Apache2 to FastCGI (Plack) ... wisdom sought

[sundialsvc4]

Esteemed Monks, I can summarize my present quandary thusly:

The Present:   An application that was written (a long time ago...) to use mod_perl, and it is entirely a custom program in that the main program includes ... well, I’ll just let the source-code itself speak for the designer’s intentions:

use Apache2::RequestRec (); # for $r->content_type
use Apache2::RequestIO ();  # for $r->print
use Apache2::Const(-compile => ':common'); # for return codes

#use APR::Table ();
#use APR::URI ();
#use APR::Error ();

# use libapreq instead of CGI.pm

use Apache2::Request ();
use Apache2::Upload ();
use Apache2::URI ();

The Goal:   To get this application, as quickly and as simply as possible, to “the real world” of FastCGI and, ex minimis, to un-do the original coder’s apparently very-proud determination to “use libapreq instead of CGI.pm.”   Even though the original coder was apparently very proud of his ability to “make two servers do the work of four,” the present reality is that very soon this legacy code base is going to have to support many different client-side platforms, and a very different server-side configuration, as well.   So, I’ve got to eliminate these “clever tricks” that presently tie the code to ... well ... to the past.

Specifically, this application ties into the httpd.conf file in the following way:

  <Location />
    SetHandler perl-script
    PerlResponseHandler my:handler
    PerlCleanupHandler my:cleanup
  </Location>
  ...
  # load the perl module that drives this bus...
  PerlRequire "directory/path/omitted.pl"

... and in the module itself ...

  sub handler {
    # get apache2 requestrec object
    my $r = shift;

    # make libapreq2 object
    my $q = Apache2::Request->new($r);
    # UNFORTUNATELY THERE ARE A -LOT- OF REFERENCES TO '$q' ...
    ...
    return $text_to_display;

One thing that I do have going for me here is that the original code was intelligently designed by a very competent coder, such that all of the stuff that drives the web-interface is located in just one sub of just one module.   There is only one other module that references Apache2, and this is just a seemingly-innocuous use Apache2::const, although there is also a use APR::Status which leads to the ominous-looking ... APR::Status::is_ECONNRESET($@) ... in a solitary if statement.

I would like to make this change while minimizing (within reason...) the number of source-lines affected.   The actual dispatching logic that is used by this application does make “a weird sort of sense,” which means that I actually might be able to simply drop a large number of the requests into it “as is.”   But I do want to get rid of the logic that is dependent upon a mod_perl deployment and that extends quite so far into the guts of Apache.   I would also like to maneuver this application so that it takes advantage of goodness like Plack while I’m here.

Incidentally:   the apparently-obvious question, “but what do you want to get rid of mod_perl for? ... mod_perl is perfection personified ... etc. ...“ can actually be put out-of-scope almost immediately.   Within the easily-foreseeable future, this application is going to have several new deployments that will not allow for this kind of too-close wedding between Apache and the app.   (In the majority of these, Apache won’t even exist.)

I humbly petition for the Wisdom of the Monks in this regard.   I shall count bit-beads upon my abacus while awaiting your reply.

[saberworks]

While the tone of this message leaves me a bit confused I will attempt to help you despite not having access to enough of the code to actually understand the structure. It seems like you have some problems with mod_perl in addition to the constraint that apache won't be available, almost as if you think programming for mod_perl is in and of itself a bad thing. I don't think anything you've posted here looks "clever" or "old" or anything else. Apache and mod_perl are proven, stable platforms that offer a lot of benefits (and like any technology choice, also some drawbacks).

The lines you see are common for mod_perl applications, they give you access to underlying apache objects that are really helpful and extremely fast compared to typical CGI.

All that said, I think you should start at the entry points of your application. Those declared in handler functions. You will have to find all the $q objects (which are similar to $cgi objects) and look at the methods that they are calling. Generally these will be compatible with $cgi although some aren't -- for example, the header handling functions are different under mod_perl.

All the "Const" includes are to pull in constants such as SERVER_ERROR or FORBIDDEN, so look for any constant (capitalized bareword in this case) that could be an http return code. You can get the full list here.

You will have to look for function calls also, like a function called "status" which sets the status of the response, any references to redirect, etc.

This is typically the opposite of what I've encountered, usually the jobs I do around mod_perl are around converting CGIs to mod_perl apps.

[sundialsvc4]

I grant you that the wording of my post sounds a little bit “odd,” but I did intend it that way.   My reasoning was, in part, to clearly convey that ... for the purposes of this project and thus of this immediate discussion, “to mod_perl or not to mod_perl, is not the question.”   It is, in fact, out-of-bounds.

Mind you, I don’t have any particular aversion to that method of web-site deployment.   With untold thousands of very-successful installations worldwide, the stability and general “good-ness” of that strategy is not in doubt.   I have used it and I would use it again.   But, for a multitude of reasons that do not have any bearing at all to “the good-ness (or not...) of mod_perl,” it’s going to be phased out for this project.   The code is going to become much more “deployment platform agnostic,” even to the point where it will no longer always be the case that Apache is even present.   Hence my attempts to carefully frame the question and to set boundaries of discussion around it.

I would love to find specific references to articles that talk about issues relating to the adaptation of the core logic of a web-application among different avenues of deployment.   (Hence my mention of mod:://Plack.)   Never mind why the choice was made, what the choice should be, or why a particular choice is right or wrong ...   what particular issues have The Monks run into when doing such a thing.   That’s my humble petition.

It would suit me just fine, and I think it would be equally relevant, if the discussion talked about “going the other way.”   References to web-sites outside of this one would be very helpful.   “Details, details.”

Now, back to counting bit-beads ... 00010101 ... 00010110 ...

[saberworks]

Well, to get you started take a look at this article about psgi and the three posts it links to (which are essentially discussions of CGI vs PSGI programming. Since you're working with a legacy application it may be difficult porting it into a framework such as Catalyst, Dancer, or Mojo. We recently did some conversions from CGI to FastCGI and it was completely painless. Going from mod_perl ought to be easy a well given what you said (essentially one entry point into the application). It seems like the community is moving away from programming specifically for mod_perl, cgi, or fastcgi and more towards programming inside these frameworks which can work under any of those.

I've been working on a Dancer app lately and have been relatively happy, it's certainly nice not having to run apache on my various development boxes.

In any case, you're likely going to have to really learn how mod_perl does things in order to safely port it to another platform.