Re: small project / experiment to learn mod

I’ll second (or third, or fourth ...) that opinion: mod_perl is not the thing to use; FastCGI is better, and (from a flexibility and compatibility standpoint), the Plack/PSGI layer is better still.

The main reason why I say that, and my motivation for now being in the process of converting an app away from mod_perl, can be summed up very simply: Pads and Phones. These interfaces aren’t going to be using HTTP web-servers anyway. It’s quite impossible to predict who the winners will be, and how many winners there will be. (Hell, they might be expecting to use our apps on their personal holodecks within five years, for all we know ...) So, applications need to be loosely coupled to the interface server(s) that drive them. mod_perl is emphatically not that way.

(Stepping quickly to mod_perl’s defense, there is no doubt that the tool was carefully and lovingly crafted to be precisely what it is, and that, under the then-prevailing engineering conditions, it might well have been the cat’s meow. It was, and is, a fine piece of software engineering.)

An app that’s written for mod_perl (without the use of a compatibility layer like PSGI) is literally “wedded at the hip to” ... Apache. It is “wedded” with the additional and very-significant cost that it makes the httpd processes large and unwieldy ... which they were never intended to be. It also makes those processes singularly responsible for anything and for everything that the web-site user may wish to do. This is far too much, and far too “tight,” coupling ... not only to a particular delivery model, but to a particular delivery server.

At this point, “hardware is cheap.” I can literally order a new cloud-server and have it at my beck and call in about twenty minutes. For a few thousand a month, I can have quite a little “farm” of them. That didn’t used to be the case. Now, the most-natural processing model is a highly-distributed one, and my natural predilection is going to be, “throw silicon at it.” I need to be able to build nimble, multi-tier application (servers) that distribute work efficiently and that support many public-facing APIs, including those not yet contemplated.

Replies are listed 'Best First'.
Re^2: small project / experiment to learn mod_perl by John M. Dlugosz (Monsignor) on May 19, 2011 at 16:38 UTC
I think there are two issues here. I agree that going with an abstract standard is better than going with a specific product, when learning the API to write your code with. In my case, I eventually needed to choose a specific product to install, so I had to figure out not the API but how to configure it and get my app running. So if you learn to write against PSGI and write your application, then you still have the chore of choosing several specific products and getting it all running.	[reply]
Re^3: small project / experiment to learn mod_perl by Anonymous Monk on May 20, 2011 at 17:55 UTC
Absolutely correct. The difficulties arise when you find that you must change the method of deployment, or even when you find that your app must support more than one method of deployment simultaneously. These are realities that are now facing us with regard to both our new and our already-installed applications. Yes, as you say, we still have to make the technical moves. Nowadays we have a very compelling need not to be boxed-in to the moves that we have chosen to make ... no matter for what then-good reasons we made them. On both the client side and the server side, “the games, they are a changin’.”	[reply]