Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Help me fill a gap in my server-side knowledge?

by Cody Fendant (Pilgrim)
on Jan 25, 2013 at 23:22 UTC ( #1015425=perlquestion: print w/ replies, xml ) Need Help??
Cody Fendant has asked for the wisdom of the Perl Monks concerning the following question:

I have built lots of sites based on perl with CGI.pm and MySQL. I'm self-taught (with the Monks' help) rather than a professional programmer.

However all of these sites have been on a stock web hosting account on an Apache server, with the simple model of:

  • browser requests URL
  • perl runs script at that URL (mostly using .htaccess and rewrite to fake "directories" so that /foo/bar/ is really ?x=foo&y=bar)
  • Apache serves up content after the script runs
  • script goes away

What I don't quite get is how the next, more professional kind of web app works, things based on Catalyst or Mojolicious etc. My question include, but are not limited to:

  • Do they require mod_perl?
  • How do you start and stop them?
  • Can I run this kind of self-contained app-and-server system on regular commercial hosting or do I need a VPS type setup where I'm root?
  • What happens if they crash or the server gets rebooted, etc?
  • Where is Plack in all this?
  • Could I easily convert my CGI-type sites to this model?
  • What makes this system better? Catalyst tutorials all say you can run the thing as CGI but it's not recommended.

As I said, I am totally confident in creating websites the "old" ("dumb"?) way, but this next step is a big gap in my knowledge. Is there a book or a tutorial aimed at taking me to that next level? Or can someone here sum it up succinctly?

UPDATE:

  • I'm getting the idea that it's not more professional to create web apps this way, simply that the frameworks are big, and that they're slow if you don't.
  • I roughly get what Plack is now.
  • Three of my questions has been answered, I now know that you stop/start them as servers the way you can start/stop your Apache with apachectl and you make sure they restart with the server by setting up your /etc/init.d just the way you set up your FTP daemon or whatever, so you need that level of control.

Comment on Help me fill a gap in my server-side knowledge?
Select or Download Code
Re: Help me fill a gap in my server-side knowledge?
by sundialsvc4 (Monsignor) on Jan 26, 2013 at 00:13 UTC

    Systems such as Catalyst or Mojolicious are frameworks that provide more of the infrastructure that are needed by ... well ... “the sort of web-sites that Catalyst or Mojolicious are good at building.”   Each of them has ecked out a particular piece of common-ground and made it very easy to build websites along the same lines.

    They also are typically designed so that they can be used under mod_perl, FastCGI, Plack, or CGI mode.

    The essential purpose of these “non-CGI” arrangements is that the software is, by whatever means, no longer repeatedly loaded and unloaded with each request, but remains persistent ... either as a Perl interpreter wedged into apache, or as a cadre of service-processes who fulfill requests handed to them by Apache.

Re: Help me fill a gap in my server-side knowledge?
by tobyink (Abbot) on Jan 26, 2013 at 00:34 UTC

    Plack is "middleware" that sits between the web development framework (Catalyst/Dancer/etc) and the server. It smooths out the differences between, say, CGI, mod_perl, FastCGI, etc so that they can be deployed in all those different ways with little effort.

    Plack-based websites can be deployed as CGI scripts. I have done this a number of times, and if you're careful you can get reasonable performance. However, if you use one of the larger frameworks like Catalyst, you'll find they run very slowly through CGI. This is because all the Perl modules used by the frameworks (in the case of Catalyst, this includes the Moose!) have to be loaded every request.

    Other deployment options allow some or all code to "persist" between requests. For example, mod_perl keeps compiled (i.e. Perl optree) copies of all the modules your script uses in Apache's memory, saving them from being re-loaded and re-compiled each request.

    Many deployment options do away with Apache or other "traditional" web servers altogether, instead using a web server written in pure Perl (or perhaps with a bit of XS to speed up the slow parts). Plack comes with the plackup tool which can be used to run many of these servers. If you've got the right permissions on the server you can write a shell script to start/stop the server and place it in /etc/init.d/ like all the other start/stop scripts on your machine that start/stop servers. Thus they'll restart when you restart the system.

    Some people will power some parts of their website with Apache and other parts with a Perl web server running on a different TCP port; they can then use Apache's mod_proxy to forward certain requests to the Perl server.

    If deploying via CGI or mod_perl, you certainly don't need root, and might not even need shell access.

    If deploying via other means, you probably want shell access and maybe root access.

    PS: here's an example of writing a tiny web app on bare Plack (no framework):

    #!/usr/bin/env plackup # Assume this file is called "greeting.psgi" my $app = sub { return [ 200, [ Content_Type => 'text/plain' ], [ 'Hello world' ], ]; };

    Just chmod +x greeting.psgi to mark it as executable, then run it at the command line. It will spawn a Perl web server on port 5000 of your computer. Type "http://localhost:5000/" into your your browser and lo and behold, a friendly greeting to the planet!

    If you want to deploy it on CGI, create an accompanying file called greeting.cgi containing just:

    #!/usr/bin/env perl use Plack::Loader; my $app = Plack::Util::load_psgi("/full/path/to/greeting.psgi"); Plack::Loader->auto->run($app);

    ... then chmod +x greeting.cgi, then visit the CGI script in your browser how you would normally.

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
Re: Help me fill a gap in my server-side knowledge?
by Anonymous Monk on Jan 26, 2013 at 01:48 UTC
Re: Help me fill a gap in my server-side knowledge?
by Shuraski (Scribe) on Jan 26, 2013 at 02:28 UTC

    Give any of them a try -- Catalyst or Dancer or Mojolicious -- you'll never want to go back to straight CGI.

    I run mine off a VPS setup. If the service crashes, you restart it.

    These MVC systems are better because you write less repetitive code, it puts the fun back into the world. Lets you get really basic stuff linked to a database running in no time, and more complex stuff running in a little bit more time after that.

    Start with the Catalyst::Manual::Tutorial. It'll get you going.

    And btw I've found Catalyst install to be no difficulty on any system with a recent perl. If all you have is something like a RHEL system, use perlbrew. Problem solved.

Re: Help me fill a gap in my server-side knowledge?
by punch_card_don (Curate) on Jan 26, 2013 at 03:39 UTC
    I'd be very interested in one of the OP's questions:

    How do you start and stop them?

    As in, once I start, for example, Dancer, running on my Apache server, does it intercept all http requests? If I have www.siteone.com already running on simple html, and I build www.sitetwo.com running on the same server (separate accounts), is Dancer going to try to interpret http requests to siteone.com? And if so, once Is tart it, if I realize it's making a mess, how do I stop it?

    Thanks.




    Time flies like an arrow. Fruit flies like a banana.
      I don't know that all your questions have been answered but see tobyink's answer. You can start and stop them the way you start and stop Apache, you can use init.d to make sure they start when the machine boots, and your two-site question can probably be answered by "they will use different ports".

        Yes in Catalyst you can assign different ports to each service you want to run. So you can run multiple websites off the same server.

        You start up your service like this:

        $ script/yourapp_server.pl -p [port_goes_here]
        Catalyst defaults to port 3000.

      As in, once I start, for example, Dancer, running on my Apache server, does it intercept all http requests?

      Depends on what you did. Only one server can operate per socket/ip combo, if you're running apache, then apache is dispatching requests to, handing off requests to, deferring processing to, dancer ... -- apache is the server, dancer is an application, whether its running via cgi/mod_fcgi/mod_perl/whatever

      Although Dancer (and most of these other frameworks, including Catalyst and Mojolicious) comes with a mini-webserver bundled into the framework, it's really only intended for development purposes, so that you can debug your app in a persistent environment without having to restart apache every time you modify the code. This HTTP server is not intended to be used in production deployments.

      For production purposes, the app would normally be mounted under a specific base URI in apache (or starman or whatever your preferred web server might be) and any requests falling under that URI get passed off by apache to Dancer, just like they would for a bare-bones script running under CGI, FastCGI, PSGI, mod_perl, or whatever. Dancer would not normally be running as a server itself.

      (If you really wanted to, I guess you could run Dancer as its own HTTP server on another port and have apache proxy requests to that port, but that would add unnecessary complexity and is neither the standard nor the intended way of doing it.)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1015425]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (6)
As of 2014-07-26 16:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (178 votes), past polls