Slashdot Mirror
E-commerce with mod_perl and Apache
rob_99 writes: "Cool new mod_perl article at perl.com documents building a large scale ecommerce solution w/ mod_perl & apache!" Pretty cool stuff - it's kind of funny to think how ephemeral their work turned out to be.
EPHEMERAL
Adjective
1. Lasting for a markedly brief time: "There remain some truths too ephemeral to be captured in the cold pages of a court transcript" (Irving R. Kaufman)
2. Living or lasting only for a day, as certain plants or insects do.NOUNA markedly short-lived thing.
ETYMOLOGY From Greek ephemeros, ep-, epi-, epi-, + hemera, day
Just in case your vocabularly sometimes leaves you wondering (as mine does).
That which does not kill me only makes me whinier
No; I haven't had that problem at all. Perl is a
good language for writing understandable code.
I was recently contacted by some people about a
web site full of cgi scripts that I wrote several
years ago. They sorta apoligized for not getting
back in touch, explaining that the code was so easy
to understand and modify that they just did it and
didn't need to contact me. But now they had some
more sophisticated needs that they weren't sure they
could program, so they thought they'd call back an
expert.
So maybe the lesson here is that I should learn to
write less readable code. Then people won't be able
to modify it themselves, and they'll have to hire
me to make trivial changes.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
But an application server it is not. Container managed persistance, transactional support, message queues, naming and lookup services? Integration with existing business objects and processes? These aren't trivial in Perl, but they are the core functionality of app servers. They pulled off clustering for eToys, but it was hardly an out of the box solution.
If all you want is a servlet container, don't spend the money on an application server. Tomcat works great and iPlanet bundles one with their web server.
Having built numerous e-commerce sites and even worked on a commercial shopping cart written entirely in Perl, I can't say that I think it's the best choice. It's great if the job is small; it's quick to code, is installed on almost all hosting providers, and so forth. But for large projects the code becomes very difficult to manage, mainly because getting people to write clean Perl code is difficult.
.xs version of the Perl client which wrapped around our C library. This has proven to be much easier to maintain.
There's a second downside: lack of good SSL networking. SSL is critical for credit card processing. I ported the GPL version of TCLink for Perl, and we ran into a lot of problems due to lack of a standard SSL library. For the first version of the client we ended up distributing a patched version of Net::SSLeay which added all of the certificate authentication functions we needed (and are missing from the standard install of Net::SSLeay). Later this became such a headache for the various platforms we were trying to support that we just coded a
Long story short: sure, Perl's great. Is it the best choice for e-commerce? I'm not so sure.
C++ guy who did industrial OO perl for two years --
.15 seconds with perl. The images loading (even on broadband) will be the gating factor on pageloads.
[quick disclaimer, feel free to use ruby or php for a substitute for perl below]
Perl is very good for a much larger range of projects than you think. [with a HUGE deference to C++/OO people, see note at bottom]. Very few sites rely on pure computational power. Most sites only need a small compenent to be fast, and that you can implement in the language of you choice with perl bindings. The majority of your site is glue -- and this is what perl does well.
I worked for a small team (5 developers) that wrote 200k lines of perl in a year and a half. That represents a far larger body of code if it had been written in another language. That isn't to say you lose control by using perl. You get to ignore the details, and in the bargain get a perfect language (and some extra time) to write regression tests.
All in all, unless you are a games site that cares about milliseconds, you can get a page out the door in under
-spRed
the deference to OO folk, you can teach people who only know C++/Java perl, you can't teach people who only know perl the others. The reason why is that real CS educations are portable. Perl [and other interpreted languages] are looked down upon by CS folk - so only non-CS folk will persue perl as a primary language. Perl is, however, extremely useful for whatever you are doing (95% of you). Give it a chance, it will save you alot of time in the long run.
.sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
If you've had a bad experience with PERL, give Perl a try!
how to invest, a novice's guide
Object Oriented Perl is extremely powerful and flexible. It's possible to do exotic things like multiple dispatch, it *does* support true encapsulation, and you can change inheritance hierarchies at run time. I've seen people write first-class objects and classes (think Self), and I've implemented mixins having seen them in Ruby. You can use all sorts of design patterns, have compile time member checking, and even modify objects as the code is running. There are even good reasons to use multiple inheritance (Perl's not the kind of language that thinks it's smarter than you.)
If you mean "member data tends to be class based instead of object based", then you're right. That's a true limitation of OO Perl. It would also be nice to have a refactoring browser like Smalltalk has.
As for readability, I can't read anything written with Kanji characters. That doesn't mean I'll ever claim it's "unmaintainable compared to English". (To be fair, complex data structure dereferencing *can be* hard to read in Perl.)
how to invest, a novice's guide
I part own an e-commerce company that's partly built with Apache/mod_perl/MySQL. We crank millions of dollars through those servers every week (porn still pays, what can you say ;-). The compile time of a script that pulls in libraries with 200k+ lines of code without mod_perl is several seconds. With, it's < 1sec. True we have/need 4GB RAM/server, but it does allow us to scale to whatever we want.
;-)
I often read articles saying perl/mysql can't handle enterprise solutions. Well, it can, does and is doing so in our case. Like any tool, it's as effective as the people wielding it.
We also have a huge codebase in C/C++, Java, Python and a few others. There's even a few NT boxes thrown in for dealing with some obscure hardware. I'm not particularly bias one way or the other, I just need the results.
By the by, I do have one solution for ensuring my programmers don't take sloppy shortcuts and write obviously quick and dirty code. It's the pink slip method. I find it works equally well in any language
Robert Nice
WebsiteBilling.com Inc.
If you're problem is even moderately interesting, there will be no out-of-the-box solutions. That Open Source might require more implementation time may be true, but the "turn-key" fantasy is most always a lie.
It seems like the primary ... use for mod_perl is to avoid the overhead associated with loading modules.
Even if you don't use modules (which would be silly, roughly comparable to not using sub-routines), you still incurr the penalty of loading and compiling your scripts each time they run if you don't use mod_perl. Also, mod_perl gives you amazing control over how the requests are interpreted and responded to. But even if it it didn't, a 5 or 6 to 1 improvement in requests/second (which is what I saw just by using mod_perl to run the script, with little of no optimization) is nothing to sneeze at.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Using Perl as opposed to, say, Java or C++, is like using Emacs as opposed to Notepad.
You can learn Notepad lickety split. You'll get alot more done if you know neither and have to get something done in a single day.
But over the long haul, you'd be far better off using Emacs.
Perl (and Python) are the same way: If you turn a bunch of inexperienced coders loose with no oversight and no structure, you'll get crap. But if you have a team of experienced Perl programmers, they will beat the pants off of any team of, say, C++ developers in terms of development time any day of the week.
Not to detract from C++. I am simply saying that the languages are used for different things, and that poor code follows from poor coding standards and practices, inexperience, and unorganized minds.
So if you can't write Perl without seeing spaghetti, I would suggest you have either some learning to do or that you need more discipline in your coding practices.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
TrustCommerce offers a drop in .pm module as well for people writing perl front ends to their web sites. The Raven SSL package allows apache to serve https, not make ssl connections from a perl program. The trouble with SSL in perl is not serving https+mod_perl, its in writing those easy drop in .pm modules for connecting to the eCommerce gateways. Lucky for all you eCommerce site developers, we gateway programmers get to worry about that, not you.
I don't think Adam's comment was meant to detract from the power of something like Mason and mod_perl for developing web site front ends. It was just that of all the API's we have open source libraries for (C, Perl, J2SE, J2EE, Python, PHP and ColdFusion), the Perl module was by far the hardest to develop as the existing tools lack some important features.
Like the subject says, you should be safe in your career. After all, you know The One True Programming Language, right? Perl isn't a toy, though, is it? I mean, if it's functionally equivalent with Ruby or PHP in all respects then it must be worth something, right? (Just don't let those interpreted guys into the Compiled Officer's Club... they might tell wild stories about getting lots of work done really quickly or spread notions about non-compiled languages being the right tool for the job...)
Seriously (or maybe not), perhaps you could check your OO bigotry at Dr. Dobbs door when you come slumming it in Scripting Land? I know some of us started using Perl before a "real" language like C++ or Java, but that doesn't make us unable to learn that real language, does it? Does it mean that we won't be able to get real work done? Are the sites we work on less useful to you?
Why would you look down on someome who has started out with Perl? I started out in the computing world using BASIC on my VIC-20. I didn't have the luxury of Java or C++. Do you think I can still learn? Am I worthy? Can I evolve to your level? Will I ever be able to look down my OO nose at mere scripters like you do? Can I be effete?
Ok, sorry to bait you. I use perl as much as I use shell scripts. I no longer use BASIC or Pascal and I'm glad. Quick and dirty GUI apps in C and C++ are a pipe dream -- Java works very well for that (especially when your app has to very quickly work on everything from BSD to WinNT). But I hate to break it to you: I have no CS eductation. The only CS course I ever took I wound up teaching. Should I resign from my job? Am I doing my company a disservice by "trying" to write OO Java apps for them since I don't have a "real CS education"? Are the OO perl apps I've written even OO enough to get me in the club? Are my C apps more portable than my lack of education? Are my Java apps?
You should realize that your "real" CS education bought you knowledge, but not at the expense of anyone else's abilities. Software Engineering is not a zero-sum game; we can all play without dimishing the accomplishments of others. But if you need to feel important, then I guess your post is like therapy for you or something...
Life is too short to be a snob.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
That C component has to go into the Apache server (and run with server privileges, with all that implies, like a potential for buffer overflow attacks) for mod_perl programs to use it.
Complete and utter BS.
What are "server privileges" ? Everything in apache runs under the nobody user (or configurable).
What potential for buffer overflow attacks? Show me one.
The component does *not* have to go into the Apache server for mod_perl programs to use it. Not even slightly. If that were the case, DBI would be unusable from mod_perl, wouldn't it? No-siree, the C component (expat) was included in Apache to support mod_dav. They modified expat slightly (and called it expat-lite), and thus we had symbol conflicts, and the wrong code being executed, and BOOM. So now Apache 1.3.22 uses the DSO expat, same as XML::Parser does, and the problems are gone.
Someone please mod me up or him down. Facts can be checked in the mod_perl and mod_perl-dev list archives.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Whats wrong with this ?
Admittedly the split function can't work on individual characters as it needs an IFS but substr seems to work ok for me.
What about this
Or have I misunderstood ?
-- Oh Well
Because just like Apache/Perl or JSP/Servlets, PHP etc. ASP can also be an adequate environment for large-scale solutions if someone with enough experience is using it. If you throw enough brains and money on a problem set, you're bound to get a good answer, no matter which technology is used (unless it has some fundamental deficiencies, of course).
As far as the article is concerned - I doubt that more than the top 1% of experienced Perl programmers could build anything like that...
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Not true. There was a clean separation. The model objects didn't have any HTML or display code in them. The templates (views) had no control flow code, only formatting. The controller knew how to pick a view, but not what was in it.
What if eToys had survived the dot-com implosion, and bought or were bought by another company? How well would this system plug into (or be plugged into) any special-needs components of the new system? That's the real acid test of maintainability in the large.
We had well-defined and documented APIs for all of the components. The hard part in integrating with another system would have been the differences in core functionality, not the interfaces.
Maybe these standards exist for perl, and I haven't used it enough in an enterprise context to stumble across them. However, you can't help but stumble across the J2EE stuff when you work with Java. Are these standards perfect? No. Are they complete? No. But they're standards, and that's what makes pluggable components possible.
Only to the extent that you can move your J2EE app from one server to another. Every J2EE app uses the basic components (EJB, JSP, servlets, etc.) in its own way. You certainly can't just connect up your warehouse management code to someone else's shipping code without a thorough agreement on the interfaces. Expecting anything more than that is just dreaming.
If you are just selling products in a plain way, you can get simple enough e-commerce. But if you want to provide good e-commerce that ties in with other content, again there are no out-of-the-box solutions. Also, you have to be happy with a out-of-the-box appearance, where you get to control a few graphics and colors on the page, but the essential layout is fixed. It's usually (but not always) pretty easy to change layout -- but that's still not really out-of-the-box.