Our application is in a state of transition from dynamically generating html on the server to providing restful web services which are consumed by a JavaScript user interface in a service oriented front end architecture. However, when we decided that that was the road we needed to go down, none of the existing perl web frameworks fit our needs so we ended up building our own web service framework from scratch. My only limitation with mod_perl is the lack of web socket support but that is easy to work around with infrastructure as a service offerings like PubNub. On Aug 18, 2015 7:42 PM, "Fred Moyer" <f...@redhotpenguin.com> wrote:
> I know of a lot of shops out there still running mod_perl. I'd say > the focus has narrowed to web services that need to be really > performant. There's a ton of web application frameworks out there, and > those that are written in Perl can be served by mod_perl via Plack, > etc. > > It's more of an API into the Apache http request cycle now than > something that directly serves up websites. Which is initially what it > started out as :) > > On Sat, Aug 15, 2015 at 9:34 AM, Randolf Richardson <rand...@modperl.pl> > wrote: > > (This reply to Dr. James Smith's message is also intended for > Ashish > > Mukherjee...) > > > > You're hooking in to more handlers than I typically do -- I hook > > into PerlAuthenHandler and PerlAuthzHandler (to implement a custom > > login system I created that uses one cookie, so it's been great that > > cookies are accessible at these stages), so that's two places (I > > found that I have to set up handlers for both or else neither works, > > which is fine because simply returning Apache2::Const::OK for authz > > is trivially easy). > > > > In my test environments, I use PerlInitHandler with > Apache2::Reload, > > which I find does come with a slight performance hit, but that's okay > > because they're not as busy as the production environments. > > > > So, aside from that I use PerlRequire to load my main module > (which > > includes the "authen" and "authz" handlers), and then I use the > > following stanza in a VirtualHost container in httpd.conf to handle > > all .pl files with mod_perl: > > > > <FilesMatch "(\.p[lm]|^[^\.]+)$"> > > SetHandler modperl > > PerlOptions +SetupEnv > > PerlResponseHandler ModPerl::Registry > > AddOutputFilter INCLUDES .pl > > Options +Includes +ExecCGI > > </FilesMatch> > > > > My main Perl module, at the authen() stage, connects to > PostgreSQL > > with DBI using connect_cached, and then stores a referenced to itself > > with $r->pnotes, which is later used by all the .pl files in my web > > sites to use the same database connection (why waste CPU resources by > > reconnecting and re-processing the cookie twice when we can just > > re-use what's already been established in the authen() stage?). > > > > One of the nice things about using the pnotes mechanism is that > it > > also means that I can write my .pl files in a generic manner so that > > they can easily be copied to other web sites that use different main > > modules (as long as I support the same functions for generating > > headers and footers, and other web site styling, which I do). > > > > For me, mod_perl has been an amazing productivity tool, and I've > > been building nearly all my web sites with it (where I don't use > > mod_perl is when all I need is plain HTML without any server-side > > functionality). One of the greatest things about using mod_perl is > > the consistently high performance it provides, even when enduring > > heavy traffic loads (there are limits, of course, but comparatively I > > find that mod_perl handles a lot more traffic than many other systems > > like PHP, and so hardware infrastructure costs are less overall too). > > > >> I agree with Randolf, > >> > >> I have watched a number of projects move away from mod_perl - often to > >> Dancer/ > >> Catalyst etc and then they ask can I do X, Y or Z... > >> > >> I say "if you were using mod_perl you could do that easily" but usually > >> find the tool chain for > >> doing something similar in Dancer or Catalyst is infinitely more > >> complex, because you can't > >> simply add a handler here or an output filter there. You can do this > >> with chained middleware > >> in Dancer but it is not that easy to implement... > >> > >> The main thing with mod_perl is - as long as Apache doesn't mess around > >> with the core HTTPD > >> interface (like they did with 2.4) then there isn't anything much that > >> needs changing - because > >> it is good solid and just works... If it ain't broke then it doesn't > >> need changing. > >> > >> I probably use more "pure" mod_perl - no registry scripts here thank > >> you! - and hook into the > >> apache process at about 7- 8 places to handle users, templating, > >> diagnostics, optimisation etc > >> > >> On 14/08/2015 18:51, Randolf Richardson wrote: > >> >> Hello, > >> >> > >> >> I wanted to enquire about the status of mod_perl, since there is > largely an > >> >> impression it is end of life. The project site also does not say > much. I > >> >> see many of the mod_perl shops now moving to perl Dancer/Mojolicious > etc. > >> >> or going the Java way. > >> > I'm still using mod_perl to develop new web sites. The most > recent > >> > one I've published is called the "atheist Blog Roll" and it uses a > >> > PostgreSQL database in the back-end: > >> > > >> > http://www.atheistblogroll.com/ > >> > > >> > There are other projects on my horizon that continue to be > developed > >> > in mod_perl, and they range from simple web sites to fully > >> > interactive projects. > >> > > >> > When there is a need for a client-side application, I use Java > >> > because I only have to write the code once to gain support on > >> > multiple Operating Systems (e.g., Unix/Linux, Windows, MacOS), and if > >> > it needs to interact with a web site, then I typically use mod_perl > >> > for that end of things. > >> > > >> > For one of the projects I'm working on (which is not ready for > >> > public consumption quite yet), I've also written a WHOIS server using > >> > mod_perl (which listens on TCP port 43, and responds to queries based > >> > on its findings in PostgreSQL) to facilitate public membership record > >> > lookups (only for the portions that will be publicly accessible). > >> > > >> >> What is the future of mod_perl beyond mod_perl 2.0? What is the > upgrade > >> >> path recommended by the mod_perl veterans? > >> > When I upgrade, I'm normally installing new server hardware and > so I > >> > migrate sites over one at a time, and resolve any API change > >> > requirements before promoting the new server to production (followed > >> > by log file merges after switching servers and traffic to the old > >> > servers cease). > >> > > >> >> Regards, > >> >> Ashish > >> > Randolf Richardson - rand...@inter-corporate.com > >> > Inter-Corporate Computer & Network Services, Inc. > >> > Beautiful British Columbia, Canada > >> > http://www.inter-corporate.com/ > >> > > >> > > >> > >> > >> > >> -- > >> The Wellcome Trust Sanger Institute is operated by Genome Research > >> Limited, a charity registered in England with number 1021457 and a > >> company registered in England with number 2742969, whose registered > >> office is 215 Euston Road, London, NW1 2BE. > > > > > > Randolf Richardson - rand...@inter-corporate.com > > Inter-Corporate Computer & Network Services, Inc. > > Beautiful British Columbia, Canada > > http://www.inter-corporate.com/ > > > > >
