Re: Scaling single-script CGI applications

[voyager]

I don't really have an answer, just more questions. I think the idea of CGI::Application is appealing, but falls apart quickly in the real world, especially if one takes the "one module for the whole application" as a feature:

• if everything is in one module, coordinating across several developers is more challenging.
• when I do db maint on a table, I often have eight (or more) modes per table:
  1. search
  2. results (list)
  3. detail
  4. update (sql)
  5. add new
  6. insert (sql)
  7. delete confirm
  8. delete (sql)
  A modest application can easily have 20+ tables, so up to 160 run modes just for table maintenance. Now in practice, I've got a module to do table maintenance (that btw, works on the principal of run modes) that is fairly simple to invoke until you go beyond default behaviors.
• The (file count) "simplicity" of one Perl module seems a bit illusory if you have an HTML template file for each run mode (3-8 for each table maintenance).
• What I do (taking the table maint case further) is to have one script for each table (or group of related tables). This script does, indeed, use the concept of run modes. I wind up with more Perl scripts, but it's easier for several coders to work without stepping on each other.
• When I have code that needs to be reused, it can be developed in the first script that needs it. When working it can be migrated to an "application module" where other scripts can reuse it. But in my case the application module only has code used more than once (or likely to be).

As with a lot of abstraction techniques, getting the granularity right is the key. A web application can be divided up a number of ways. I look at these levels:

• An individual page
• A group of related pages that never go anywhere without each other.
• The whole application (or sub-application)

The page is smallest unit. The related pages are not arbitrary: you can't have a search page without a results page. The "whole application" is somewhat arbitrary.

When you add functionality to a web site, it is usually done in chunks of "groups" of pages. Programmer responsibililty is frequently at the group level. Your "code orthogonality" is likely at the group level. So my conclusion is that right granularity for managing an application is at the "group of related pages" level. I usually have a perl script for each such group.

I'd be curious to hear from people who used CGI::Application or similar for small, one-person tasks and find out what happened when the size of the project and project team grew substantially.

[Hero Zzyzzx]

Your points are good, but I think you're focusing on the idea of "one module is the application" related to CGI::Application too much.

The way I use CGI::Application is I write a central module, "SuperClass.pm" that has shared functions for all my other modules that make up an entire web application. I then use this SuperClass in all my application modules.

Example:
Here's SuperClass, the shared base class for all my modules.

Package SuperClass.pm
use DBI;
use whatever_else_you_want;
use base 'CGI::Application';

sub cgiapp_init{
   my $self=shift;
   ## initialize variables, stuff them into params to allow
   ## all other modules to inherit common functions. For
   ## instance, I'll set up my DBI connection, user
   ## authentication,  HTML::Template object, etc. all in 
   ## here. Then every object from here on down can access
   ## them.
   }


Here's an application module, UserManager.pm, which inherits many of it's functions from SuperClass.:


package UserManager;
use base 'SuperClass';

sub setup{
   my $self=shift;
   my $q = $self->query(); #Get CGI.pm object
   $self->start_mode('print');
   $self->mode_param('rm');

   $self->run_modes(
      'login'=>'login',
      'delete'=>'delete',
      'list'=>'list'
      #More run modes here.
   );
}

sub login{
   #do stuff here according to what's inherited from 
   #SuperClass- For instance, use the HTML::Template
   #that SuperClass specifies. This greatly increases
   #reusability.
}

I then build all my other application modules split logically into appropriately named .pms', but all still sharing the same core. e.g. there's a UserManager.pm, Survey.pm, RSS.pm, Search.pm, etc.

I don't think of developing with CGI::Application like I need to stuff everything into one module at all, put your shared functions into a "SuperClass" and then use that as the API that you develop the rest of your application modules around.

Though I'm pretty much a "lone-wolfer," this methodology seems to lend itself very nicely to working with a team: You articulate to them what is provided by SuperClass, and they code around it. If you need to figure out what someone wrote, you just look at their run modes and you can very easily figure out what's happening. Seems pretty scalable to me.

Hope this helps! I really suggest that anyone looking to make webapps look closely at CGI::Application. It enforces good coding standards, uses the excellent HTML::Template module to great effect, and is very flexible and lightweight.

[voyager]

It sounds like we are largely in agreement. And I'm not the one " ...focusing on the idea of 'one module is the application' related to CGI::Application too much. "

From the Abstract of CGI::Application's documentation:

The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of ``Run-Modes.'' Each Run-Mode is roughly analogous to a single screen (a form, some output, etc.). All the Run-Modes are managed by a single ``Application Module'' which is a Perl module.

Since the subject of the node is "Scaling single-script CGI applications" (my emphasis) I thought it important to point out that the single-module approach is not the way to go. But we agree on that, right? :)

[Hero Zzyzzx]

Yes. Sorry I didn't articulate it very clearly, but what I was getting at is that you can create a central repository of shared stuff, and then split out your major functions into different modules, not a single script application. CGI::Application makes this very easy, and this functionality is very well thought out by the author, Jesse Erlbaum.

If you were thinking of starting an application as a single script, with the idea that you may split it out later, CGI::Application would be a good way to start.

When you were ready to split your single script app up, you'd put your setup() or cgi_appinit() subs into your shared SuperClass and your other modules could run pretty much untouched.

This might be a good way to go: Develop with CGI::Application for all it provides for a single script app, AND because it'll set you up better down the road as you need to bump up your script's functionality.

[markjugg]

Hello!

I converted a moderate sized application to use CGI::Application and I've been very happy with as an organization tool and framework. I would consider using it for all but the most trivial CGI projects. You can visit the Cascade homepage to read more about the software, demo it and download it.

-mark