LNPPCF vs. LAMP
Every day it seems that someone is writing introductions and reviews about how awesome using the so-coined LAMP (Linux, Apache, MySQL & PHP) stack is. I too was once a lover of this choice of software for getting things online, however over the past few years I’ve slowly replaced most of those with other free alternatives and haven’t looked back for a moment. This website, along with most others that I look after nowadays, are running what I guess you could call a LNPPCF stack. That is Linux, Nginx, PostgreSQL and Perl with Catalyst and FastCGI.
My reasoning behind this? Well, for all intents and purposes Postgres seems to be very much alive in terms of regular releases and the fact that it has a huge following and ample resources online for learning and working with it. The official docs are also second to none, but should you still be having trouble getting your head around why your queries are running slowly, or not at all, there’s always the #postgres channel on FreeNode where people are generally more than willing to share their expertise and opinions (and in the traditional IRC manner, flame your ass if you’re being an ubern00b).
Postgres also doesn’t allow you to do Stupid Shit™. A friend and I were having trouble with data in a MySQL database of ours disappearing or being truncated for no obvious reason. The culprit was a VARCHAR column with a length set. MySQL was simply truncating anything we tried to store in this column, and then going on it’s merry way. Postgres in the same situation essentially blows up with a (somewhat helpful) error message, and doesn’t commit the transaction to the database. IMHO, this is a much better thing to happen – I don’t want to assume all my data is stored in full and safe, only to find that half of it has been thrown away by my DBMS. It can also point out flaws in table definitions, the database structure or in the code interfacing with the DB.
As for my choice of Nginx over Apache it’s fairly simple. It’s powerful, fast, light and modular. The config files are laid out in a more sane format (perhaps its the fact that they mostly resemble a big Perl-ish datastructure), the docs are extremely helpful and most if not all things that Apache is capable of are achievable with relative ease, perhaps more.
My choice of Perl over PHP was honestly the biggest hurdle to overcome. It’s sometimes cryptic syntax took a while to come to terms with, but again Perl has an amazing community lurking behind it, and for a beginner it shouldn’t be too hard to get up and running with a little practice and some guidance and support from the veterans that are out there. I think the biggest benefit of Perl is the CPAN. It’s a goldmine of code which you can take advantage of. With a big push towards code reuse, and not rebuilding the wheel for each menial task you have to deal with in your daily programming adventures, there’s bound to be something on the CPAN to help you out. Another great thing is when you need to achieve task X, but aren’t quite sure of the intricacies that would be required to implement a solid solution. If you’re lucky you’ll be able to find a module that has been developed, tried and tested by the community (which may or may not have very great documentation – YMMV there) which you can use to help out along the way. CPAN puts PHP’s Pear to shame.
There is also an ever-growing amount of awesome web frameworks out there for Perl. Catalyst, Mojolicious, Dancer – the list goes on, as do the reasons why you would choose one over the other. Personal preference tends for me to use Catalyst for most projects, however I’ve dabbled with some of the others (namely Mojolicious) for smaller projects.
Then comes FastCGI which basically ties my Perl projects nicely into Nginx, and gets everything up and running online. Most of the Perl web frameworks out there come with some form of inbuilt testing and development server, but so far FastCGI seems to be the best route to go down in terms of actual production-ready serving of “stuff”.
All in all, it really comes down to personal preference and what languages and technology you’re most comfortable and familiar with. But given the choice, why not explore something a little left-of-center for your next project? You may be pleasantly surprised by what you can achieve.