Perl Web Development From Outer Space
An absolute beginner's guide
Please note, this is an incomplete, early draft. It is still not complete. Some of the missing/incomplete sections are marked with class="TODO" and a red background, but those are by no means the only areas needing improvement.
Introduction
If you search for tutorials and guides for making dynamic web applications using Perl, you'll be sorely disappointed, grossly misled, or both1. There is a lot of information available online, but unfortunately, it's mostly either really old or really technical.
You can easily create your site using tools and technologies from the web's stone age, following some "CGI Scripting" tutorial near the top of google's search results2. Eventually you will probably discover an unnecessarily long and hard lesson with an unhappy ending though. There's a reason things have evolved in the past decade.
So maybe you could instead ask some veteran Perl web developers, "Hey, I want to create a robust, scalable, butt-kicking website; where do I start?" They'll tell you to use plack. You'll then spend an hour or two searching through reference documents, each assuming you know and understand another separate stack of documents. You'll get trapped in a vicious loop of nitty-gritty details and nobody will ever pull you out of it and tell you where to start.
Perl, with the help of the CPAN, is the most mature, stable, robust, powerful, and feature-filled language for developing web applications. But it's easy to get lost in the sea of options and their details.
How do all these pieces fit together?
Which ones do I need?
Which ones can I ignore?
How do I actually make a website?!
From space?
That's where this guide comes in. Before you get lost in the details, we're going to take a step back - actually many steps back - we're going to zoom out. All the way out.
To space.
And we'll look at the big, wide picture from space, absent any of those details we see on the ground (or in the wealth of documentation on the CPAN).
Should I read this guide?
If you...
- are new to Perl, or
- are new to web development, or
- hear the buzz about "PSGI" and "Plack" but aren't sure how it all fits together, or
- plan to write something using CGI, FastCGI, or mod_perl3
... then yes. Yes you should read this guide. So let's get started! To understand where we are now, and where we are headed, we must first examine where we began.
Website architecture deployment options
Choices, choices, choices....
There are countless ways to use Perl to power your web site. This is especially true since Perl was one of the earliest computer languages used to serve dynamic content. We've had a long time to try a lot of things.
We're going to take a walk with the ghosts of web development's past, present, and future.
Be warned though, if you're a stickler for details and want a complete history of web development with citations and references, this isn't the guide for you.
In looking at the tools of yesterday, we'll just consider three of the most common ways web sites were written and deployed: CGI, Apache and mod_perl, and FastCGI. We will also simplify the complex histories and try to understand these as a sequential evolution, to better grasp their strengths and weaknesses and see how they came about, then fell out of favor.
Yesterday
CGI the explosion of a dynamic web
In the earlest days of the web, it was terribly difficult to create dynamic content. In order to allow a web server to dynamically respond to custom requests, people actually modified the source of the web server itself. This was not only time-consuming to implement, but it presented a lot of maintenance challenges.
Figure 1) CGI deployment
not recommended With each request, the server forks a new process to run the CGI script. CGI is simple, but inefficient.
Some of these early web pioneers then came up with the Common Gateway Interface (CGI), which allowed them to create separate programs that could be run by the web server. This made it simpler for people to develop and share custom web applications. These early CGI programs were written in C, the low-level language of the web server.
While C is very popular, and extremely powerful, it is nevertheless cumbersome and labor intensive for certain types of tasks. Around the time CGI was picking up speed, so too was Perl becoming more popular and widely used. C's usage for web applications was short lived as people found Perl to be a perfect fit for processing web requests.
Perl quickly became the defacto language for the web, and CGI its vehicle.
As the web began to get more and more traffic, though, and as the demands for web applications required ever-increasing complexity, the limitations of CGI began to strain many servers.
Specifically, as the web server receives each request, it forks a separate process to run the CGI script. Or said another way: it's quite inefficient.
Figure 2) mod_perl and Apache deployment
not recommended mod_perl applications are embedded in the web server for efficiency, but are considerably more complex than CGI.
This was significant because, unlike CGI, you could now write Perl web applications that continued to run (albeit idly) even after a request had been finished, and could therefore be reused for multiple requests.
This eliminated much of the startup time and allowed for more efficient and quicker web applications.
But these benefits came with a cost. Writing an Apache module is fairly complicated. It easily trips up a novice programmer and gives them many opportunities to introduce bugs. And when it comes time to fix those bugs, debugging a mod_perl application can be quite an ordeal.
And finally, an obvious drawback that shouldn't be overlooked is that a mod_perl application forever ties you to Apache. You will not have the opportunity to easily look for performance enhancements and greater efficiences (and therefore cost savings!) with alternative web servers such as nginx or lighttpd.
FastCGI the best of both worlds
...
Figure 3) FastCGI deployment deployment
not recommended
TODO: Write this...pretty decent, and still a good choice for deploying, but don't write your application specifically for FastCGI. We now have a more general and flexible way to write web applications... blahblah. ?
Today
Along came PSGI
... Explain web applications in general, and how PSGI simplifies this. Req > Processing > Response
...iBlah blah blha...
Figure 4) Web application
A web application simply takes a request, does some processing, then returns a response.
Standalone direct-access to application
...
Figure 5) Directly serving PSGI application
Your PSGI app can be run by a specialized, standalone HTTP server such as HTTP::Server::PSGI.
...floating...
Behind a reverse proxy
...
Figure 6) Reverse proxy deployment
recommended If you don't know where to begin, this is a very powerful but simple way to deploy both small and large websites.
...floating...
Behind a reverse proxy - more options
...
Figure 7) Reverse proxy deployment
...floating...
The possibilities are endless
...
Figure 8) Add caching, or anything else to the stack!
...floating...
Figure 9) Easily distribute the load across multiple servers
...floating...
My hosting plan won't let me do any of this...
Remember when we said using CGI, FastCGI, or Apache mod_perl is not recommended? Well, that's not entirely true.
The important thing is to avoid writing our web application specifically for CGI, or specifically for FastCGI or specifically for Apache. Yet another benefit of writing a PSGI-capable application is that you can wrap your code in a handler to serve it any way you need.
In other words, your PSGI web application can be deployed as a CGI, FastCGI, mod_perl Apache handler, and more.
Figure 10) Deploying PSGI app with CGI using Plack::Handler::CGI
Figure 11) Deploying PSGI app with mod_perl and Apache using Plack::Handler::Apache2
Figure 12) Deploying PSGI app with FastCGI using Plack::Handler::FCGI
Tomorrow
PSGI: Future-proofing no more rewrites!
In all fairness, we can't promise this is the be-all-end-all for web development until the end of time. But it's close enough and will last a long, long time. Why can we say that?
PSGI is dead simple.
... just a specificiation. Takes a hashref, returns an array ref. ... doesn't try to do too much. Leaves the important details up to you ... the result is that we are much less likely to try to replace it with something else. Instead, we build upon it. ... But you don't need to actually know or understand it, just use the tools that do.
It's widely accepted and adopted throughout the Perl community, and implemented nearly everywhere. The application you write today using PSGI will remain, for many years to come, deployable in pretty much any scenario, on any platform, and in any software stack.
So what's this plack thing?
plack. ... + middleware explanation ...Note about the Plack::Handler::* examples above...
... point out that most plack stuff is primarily for framework authors.
Getting your feet wet
My first web application
So now you know a handful of ways sites can be deployed, and are convinced PSGI is the way to do it, how do actually do it?
...introduction...
Web frameworks
... choose framework, choose deployment tools...
... example: web::simple, then nginx+starman
Resources
Keep going some tools to be aware of
...
Frameworks
Interesting middleware
Wait... what is middleware?!
...
Deployment options
...
Appendix
Footnotes
1 As of April 2012. But hopefully you're reading this in a future when there are plentiful up-to-date, accurate, and useful Perl web programming resources!
2 Because the dynamic web was built largely on the back of Perl, there's no end of Perl+CGI tutorials written in the late 90s and linked zillions of times over. The unfortunate result is that finding good, modern information with google is well-nigh impossible. So I'm especially glad you found this!
3 If you plan to write something specifically for CGI, FastCGI, or mod_perl (not to be confused with writing something to be PSGI-capable, then deploying with one of those)... then just make sure you have a very good reason! Chances are, you simply want to deploy with one of those, and PSGI and Plack can help!
Contributions welcome
- Fork this repository on github to submit your corrections and enhancements.
- Suggestions and ideas may be submitted on the Issues page.
Credits
- Your name here...