perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Warren Young <>
Subject Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
Date Thu, 22 May 2014 19:55:13 GMT
On 5/22/2014 11:01, Josh Chamas wrote:
> You know I have not much followed the routing paradigms.  To me it seems
> that this would be an area I would have solved with a mod_rewrite or a
> mod_perl handler, changing up the URL destination on the back end.

Routing is more than just an abstraction between the implementation 
level and the presentation to the browser.  It forces you to consider 
your logical URL structure.

My Apache::ASP code just growed, like Topsy.  One page at a time, with 
no consideration of the interfaces exposed by the other pages.  There 
was consistency of design only to the extent that there was code 
copying, and then in decreasing fashion with respect to time, as the 
cloned pages diverged.

As soon as I started developing a system of routes in the Dancer port, I 
realized that I had an API.  It was sitting there the whole time, never 
identified in the Apache::ASP form, but there it was in the Dancer code, 
clear as day.  Once I'd formally extracted it, I spent a day redesigning 
it the way it should always have been.  The correct design popped right 
out, obvious as a green sky.

This happens because you have to describe your URL structure to Dancer, 
one URL per line.  Many fit in a single screen of text, so patterns jump 
out at you.

Example in Dancer pseudocode:

     get '/' => ...
     get '/login' => ...
     get '/logout' => ...

     prefix '/app' => sub {
         get 'page1' => ....
         get 'page2' => ....

     prefix '/api' => sub {
         del  'foo/:id' => ...
         get  'foo/:id' => ...
         post 'foo' => ...
         put  'foo' => ...

         get  'bar/:id' => ...
         ...same as foo...

The story this route structure tells is clear:

1. First you go to the top level page, which perhaps has a Log In link 
or button to send you to the /login page.

2. The /login page creates a session and bounces you to /app when you 
log in successfully.

3. There's a button or link somewhere that sends you to /logout, which 
destroys your session and sends you back to / or /login.

4. The app does CRUD-y things to "foo" and "bar" objects through 
/api/{foo,bar}, creating via PUT, reading via GET, updating via POST, 
and deleting via DELETE.  GET and DELETE require a record ID to tell the 
handler what to operate on, while PUT and POST must be fairly complex in 
what they will accept, so that the parameters cannot be marked as 
required in the route structure.

It's kind of like that Fred Brooks quote, "Show me your flowcharts and 
conceal your tables, and I shall continue to be mystified. Show me your 
tables, and I won’t usually need your flowcharts; they’ll be obvious."

> I wonder if Apache::ASP were to be made to work
> with something like Plack, if it would pick up some routing potential on
> the way (or maybe just a Plack way of doing things?)

I don't think so.  I believe a minimum-effort Apache::ASP Plack port 
would have only one feature relative to Apache::ASP v2, that being web 
stack independence.  From your perspective, the big difference is that 
you have to replace all the mod_perl Apache2::Foo stuff with Plack/PSGI 

To get a handle on what routing does for Dancer, say:

     $ sudo cpanm Dancer
     $ dancer -a foo

This generates a complete, self-contained sample app, suitable for 
hacking on directly.  That is to say, the file and directory structure 
it generates is suitable for production use.

The routing structure is in foo/lib/  You also use this file to 
define hooks, which are roughly equivalent to global.asa event handlers 
in Apache::ASP.  Script_OnStart is the same as Dancer's "before" hook, 
for example.  There is no direct equivalent of Session_OnStart, but you 
can build that into the "before" hook, too.  The Dancer equivalent to 
the Application_* event handlers is foo/bin/

If Apache::ASP were to get a routing system, I don't know that you'd 
necessarily want to put it in global.asa.  It works well for Dancer, but 
perhaps another design would make more sense for Apache::ASP, since 
global.asa has historical meaning.

Notice, by the way, that foo/lib gets added to @INC by foo/bin/ 
This solves another problem I had with Apache::ASP, which doesn't like 
you to define functions and classes in your *.asp files.  You end up 
creating *.pm files to hold all reused and complicated code.  Where then 
do you put those *.pm files so that mod_perl can find them?

In my Apache::ASP app, I ended up installing them into the system's 
site_perl directory, and then I could never remember the path to those 
files when I had to hand-hack one of these files on a production server 
to test a problem fix in the field.  With Dancer, the *.pm files are 
right there next to the rest of the app.

>> The most problem with Apache::ASP for by now is that it is tied to
>> mod_perl
>> with it's module reloading ,memory hogging problems.
> Yes, always been a problem, but memory is so cheap! :)

I know you're joking, but RAM on VPSes isn't cheap.  4 GB more RAM in my 
colocated box is virtually free.  4 GB of RAM added to my cheap 
bare-bones VPS plan adds another $35/mo, or $420/yr, or $2,100 over the 
expected lifetime of the server.

There's another advantage of Dancer.  By going with a single long-lived 
app process instead of forking off Apache children, and by making that 
app independent of tubby ol' Apache, we can squeeze our app into much 
smaller VPSes and VMs.

In extreme situations, you don't even need a traditional web server. 
That "foo" app I had you create above?  It contains a perfectly usable 
basic web server, listening on port 3000.  Run it as root so it can bind 
to port 80 instead or port-forward 80 to it, and you've got an entirely 
self-contained app.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message