I have been trying to decide if my web project is a candidate for implementation using PSGI, but I don't really see what good it would do for my application at this stage.
I don't really understand all the fuss. To me PSGI seems like a framework that provides a common interface between different Apache modules which lets you move your application between them. e.g Easily move your application from running on mod_perl to fastcgi, and provide the application support for running on both options.
Is that right, or have I missed something?
As I and the team I am a part of not only develop the application, but also pretty much do maintenance and setup of servers I don't see the value for us of being able to run on fastcgi, cgi, and mod_perl, we do just fine with just mod_perl.
Have I misunderstood the PSGI functionality, or is it just not suitable for my project?
Forget the Apache bit. It's a way of writing your application so that the choice of webserver becomes less relevant. At $work we switched to Plack/PSGI after finding our app running with very high CPU load after upgrading to Apache2 - benchmarking various Apache configs and NYTProf'ing were unable to determine the reason, and using PSGI and the Starman webserver worked out much better for us.
Now everything is handled in one place by our PSGI app (URL re-writes, static content, expiry headers, etc) rather than Apache configuration, so it's a) Perl, and b) easily tested via our standard /t/ scripts. Also our tests are now testing exactly what a user sees, rather than just the basic app itself.
It may well not be relevant to you if you're happy with Apache and mod_perl, and I'm sure others will be able to give much better answers, but for us not having to deal with anything Apache-related again is such a relief in itself. The ease of testing, and the ability to just stick in a Data::Dumper and see what's going on rather than wrestling with ModRewrite and friends, is a great boon.
Borrowing from a recent blog post by chromatic, Why PSGI/Plack Matters (Testing), here's what it is:
It's a good idea borrowed from Python's WSGI and Ruby's Rack but made Perlish; it's a simple formalizing of a pattern of web application development, where the entry point into the application is a function reference and the exit point is a tuple of header information and a response body.
That's it. That's as simple as it can be, and that simplicity deceives a lot of people who want to learn it.
An important benefit is, ibid.,
Given a Plack application, you don't have to deploy to a web server—even locally—to test your application as if it were deployed … Plack and TWMP (and Plack::Test) use the well-defined Plack pattern to make something which was previously difficult into something amazingly easy. They're not the first and they won't be the last, but they do demonstrate the value of Plack.
Started wrote an answer and after 50 lines I deleted it. Simply because it is impossible tell (in short) why is PSGI extremely cool. I'm new in PSGI too, but zilion things now are much easier as before in my apache/mod_perl era.
I can give you next advices:
read the Plack advent calendar - all days, step-by-step. You must understand the basic philosophy, what is good on onions and so on... :)
search CPAN for "Plack::Middleware::" - and read the first few lines in each. Here are MANY. (Really should be somewhere some short overview for each one, unfortunately don't know any faster way. Simply it is good to know, what middlewares are already developed. (For example, you sure will need the Plack::Middleware::Session, or Plack::Middleware::Static and so on...)
read about Plack::Builder (already done, when you done with the advent calendar) :)
try write some apps with it and will find than Plack is like the first sex - now you didn't understand that you could live without it.
ps:
If was here something like "Perl Oscar", will sure nominating MyiagavaSan. :)
Related
I'm beginner of Perl.
My understanding is below.
FCGI is a protocol
It is a gateway interface between web server and web applications
The process keeps alive for specific period(such as 5 mins) and accepts multiple requests, so response is fast.
You cache some data before process is build so that you can share those caches with all process, and you can save memory by Copy-on-Write.
It looks nice.
However, I have never seen FCGI in my experience with modern development with Golang, Nginx or whatever.
Doesn't modern web application require FCGI anymore?
What was the disadvantage of FCGI, and what is the still advantage of FCGI?
If we say there are better alternatives/ways that will be proper statement instead of saying anything dead or alive. Still in 2021 I have seen code running with FCGI in production and its going good. The latest comment happens in 2019 in the github. Everything has a time frame. Being old doesn't mean bad/dead, being younger doesn't mean good/alive.
For modern web development there are many frameworks available right now -
Catalyst
Mojolicious
Dancer2
Kelp
Raisin
Top 3 are most common ones. Mojo is mine personal favorite.
You can use them with Plack/uWSGI and you are good to go in no time. They will take care of everything.
Since you mentioned "FastCGI is a protocol" and it is not an implementation, it shouldn't be specific to any language. There will be implementation across different language(maybe not popular). You can find them with single search. One example of Nginx
There are various other questions asked before similar to this. Have a look at those. They will give you more clarity.
Is there a speed difference between WSGI and FCGI?
Is mod_perl what I'm looking for? FastCGI? PSGI/Plack?
Perl CGI vs FastCGI
Which is better perl-CGI, mod_perl or PSGI?
To expand slightly on Maverick's answer...
When writing a web application, there are two questions you need to ask yourself:
What language/framework am I going to write this application in?
How am I going to deploy this application?
In the bad old days, the answers to the two questions were intertwined in annoying ways. You might write a CGI program originally and then switch to a different deployment environment (FCGI or mod_perl, perhaps) at a later date when you wanted better performance from your application. But changing to a different deployment environment would usually mean making a lot of changes to your code. The application needed too much knowledge about the deployment environment. And that made life hard.
If you use the frameworks in the other answer, then things are different. Most (maybe all) of those frameworks run on top of a protocol called PSGI (Perl Server Gateway Interface). By writing your application using those frameworks, then your application will interact with the web server using the PSGI protocols. And there are PSGI adaptors available for all web deployment environments. So you can start by deploying your Dancer2 application as a CGI program (very few people do that, but it's completely possible) and then move it to an FCGI or mod_perl environment without changing your code at all.
I still see people deploying applications in FCGI. It's certainly more common than using mod_perl these days. But, to be honest, the most common deployment environment I see is to set your application up as a standalone service running on a high port number and to use a server like nginx to proxy requests to your service. That's what I'd recommend.
I am looking to start Web Programming in Perl (Perl is the only language I know). The problem is, I have no prior knowledge of anything to do with the web, except surfing it. I have no idea where to start.
So my question(s) is...
Where do I start learning Web Programming? What should I know? What should I use?
I thank everybody in advance for answering and helping.
The key things to understand are:
What you can send to browsers
… or rather, the things you intend to send to browsers, but having an awareness of what else is out there is useful (since, in complex web applications in particular, you will need to select appropriate data formats).
e.g.
HTML
CSS
JavaScript
Images
JSON
XML
PDFs
When you are generating data dynamically, you should also understand the available tools (e.g. the Perl community has a strong preference for TT for generating HTML, but there are other options such as Mason, while JSON::Any tends to be my goto for JSON).
Transport mechanisms
HTTP (including what status codes to use and when, how to do redirects, what methods (POST, GET, PUT, etc) to use and when).
HTTPS (HTTP with SSL encryption)
How to get a webserver to talk to your Perl
PSGI/Plack if you want modern and efficient
CGI for very simple
mod_perl if you want crazy levels of power (I've seen someone turn then Apache HTTPD into an SMTP spam filter using it).
Security
How to guard against malicious input (which basically comes down to knowing how to take data in one format (such as submitted form data) and convert it to another (such as HTML or SQL).
Web Frameworks
You can push a lot of work off to frameworks, which provide structured ways to organise a web applications.
Web::Simple is simple
Dancer seems to be holding the middle ground (although I have to confess that I haven't had a chance to use it yet)
Catalyst probably has the steepest learning curve but comes with a lot of power and plugins.
Dependent on complexity of your project, you could have a look at Catalyst MVC. This is a good framework, messing up with the most request stuff, but gives you enough in deep view whats going on.
There is a good tutorial in CPAN
If you want to start with mod_perl or CGI, there are also some Tutorials :
mod_perl
CGI Doc
If you're looking to try some web programming in Perl, you could try hosting a Dancer app for free on OpenShift Express.
There's even a "Dancer on OpenShift Express" repo to get you started: https://github.com/openshift/dancer-example
Things have changed way too much in the bussines logic for our Flex 3 customer extranet application, so I have received the permision to make a fresh start... with low date pressure (I know, you envy me...).
Instead choosing the obvious Flex 4 path, it seems that Perl/Catalyst fits very, very well in this brand new scenary, but I don´t want to lose some goodies:
We have just ONE set of .swf modules, so all clients load the same actual files in a shared path.
They are Virtual Hosts.
Each domain directory has a index.php. It loads a personalization file with passwords AND the "real" shared index.php that loads the shared .swf.
No crossdomain problems because the .swf thinks that its in the true domain, thanks to the Apache virtual link.
All personalization inside the .swf (bussines data and visual prefs) are loaded dinamically from preferences in a database
It seems that I can do the same with Catalyst, isn´t it? Even easier, because I can make the perl app to respond "globally" to the same arguments in different vhosts, so everything can be decide at runtime
But the great advantage of Flex is that I have all the logic and preferences already loaded in the client, so the work in the server and the data transference is really, really low. The only data that travels is pure bussines data. No preferences, no pages, no nothing. And the app always know WHO the client is, so the queries are really, really clean.
So here are my two questions:
Is the Persistence in Perl/Catalyst a way to manage something similar?
I have read a lot of posts, here and there, about unclosed processes and threads, even cron programmed restarting of the server... as a "solution", and similar performance problems.
Must I manage such things to have a stable server?
It sounds ike a time bomb, and we are now very, very proud of our server perceived performance with a litle investment.
Thank you in advance
The nice thing about Catalyst is that it is very easy to plug all sorts of nice things from CPAN into your application. You need Authentication/Authorization, Session management, database handling, PDF generation, Excel parsing....? If you can think of it, someone on CPAN has probably done it already and published it for the world to use.
It is not exactly clear to me what you want the server to do. If it's just providing data to your SWF application through JSON or something similar, Perl Dancer (http://perldancer.org/) might also be interesting to look at, it's like Catalyst on a diet. Both Catalyst and Dancer have built in PSGI support allowing you to run it in any way you like.
Myself, I have just recently finished a project for ABN AMRO Bank Luxembourg in which I used Catalyst as the backend solution for an ExtJS application. The application is run under FastCGI and is extremely robust and stable. i don't know where you heard that Catalyst processes are leaky and need to be restarted, but that's just nonsense. Of course, if you program leaks yourself you might get yourself in problems, but the framework itself is very stable. Also, because of using Catalyst I was able to develop a very complex application is a very short time. I don't know how I could have managed it without Catalyst.
Good luck with you project
Rob
I learn best by taking apart something that already does something and figuring out why decisions were made in which manner.
Recently I've started working with Perl's CGI::Application framework, but found i don't really get along well with the documentation (too little information on how to best structure an application with it). There are some examples of small applications on the cgi-app website, but they're mostly structured such that they demonstrate a small feature, but contain mostly of code that one would never actually use in production. Other examples are massively huge and would require way too much time to dig through. And most of them are just stuff that runs on cgiapp, but isn't open source.
As such I am looking for something that has most base functionality like user logins, db access, some processing, etc.; is actually used for something but not so big that it would take hours to even set them up.
Does something like that exist or am i out of luck?
CGI::Application tends to be used for small, rapid-development web applications (much like Dancer, Maypole and other related modules). I haven't seen any real examples of open-source web apps built on top of it, though perhaps I'm not looking hard enough.
You could look at Catalyst. The wiki has a list of Catalyst-powered software and there are a large number of apps there - poke around, see if you like the look of the framework. Of this, this is Perl, so some of those apps will be using Template::Toolkit, some will use HTML::Mason... still, you'll get a general idea.
Try looking at Miril CMS. Although I don't know in which state it is.
I am the same with code, and had the same request. When I did not find a solution I created my own. which is https://github.com/alexxroche/Notice
I hope that it is a good solution to this request.
Notice demonstrates:
CGI::Application
CGI::Application::Plugin::ConfigAuto
CGI::Application::Plugin::AutoRunmode
CGI::Application::Plugin::DBH
CGI::Application::Plugin::Session;
CGI::Application::Plugin::Authentication
CGI::Application::Plugin::Redirect
CGI::Application::Plugin::DBIC::Schema
CGI::Application::Plugin::Forward
CGI::Application::Plugin::TT
It comes with an example mysql schema, but because of DBIC::Schema it can be used with PostgreSQL, (or anything else that DBIx::Class supports.)
I use Notice in all of my real life applications since 2007. The version in github is everything except the branding and the content.
Check out the Krang CMS.
Every time I see Ruby or Python discussed in the context of web development, it's always with a framework (Rails for Ruby, Django for Python). Are these frameworks necessary? If not, is there a reason why these languages are often used within a framework, while Perl and PHP are not?
I can only speak towards Ruby - but, no, you don't need a framework to run Ruby based pages on the web. You do need a ruby enabled server, such as Apache running eruby/erb. But, once you do, you can create .rhtml files just like RoR, where it processes the inline ruby code.
The short answer is no, they are not necessary. In ruby you have .erb templates that can be used in a similar way as you use PHP pages. You can write a site in ruby or Python using several technologies (Rails-like frameworks, Templates or even talking directly with the HTTP library and building the page CGI-style).
Web frameworks like Python's Django or Ruby's Rails (there are many) just raise the level of abstraction from the PHP's or ASP's, and automate several process (like login, database interaction, REST API's) which is always a good thing.
"Need" is a strong word. You can certainly write Python without one, but I wouldn't want to.
Python wasn't designed (like PHP was, for example) as a direct web scripting language, so common web-ish things like connecting to databases isn't native, and frameworks are handy.
EDIT: mod_python exists for Apache, so if you're merely looking to write some scripts, then Python doesn't need a framework. If you want to build an entire site, I'd recommend using one.
From a Pythonic point of view, you'd absolutely want to use one of the frameworks. Yes, it might be possible to write a web app without them, but it's not going to be pretty. Here's a few things you'll (probably) end up writing from scratch:
Templating: unless you're writing a really really quick hack, you don't want to be generating all of your HTML within your Python code -- this is a really poor design that becomes a maintainability nightmare.
URL Processing: splitting a URL and identifying which code to run isn't a trivial task. Django (for example) provides a fantastic mechanism to map from a set of regular expressions to a set of view functions.
Authentication: rolling your own login/logout/session management code is a pain, especially when there's already pre-written (and tested) code available
Error handling: frameworks already have a good mechanism in place to a) help you debug your app, and b) help redirect to proper 404 and 500 pages.
To add to this, all of the framework libraries are all heavily tested (and fire tested). Additionally, there are communities of people who are developing using the same code base, so if you have any questions, you can probably find help.
In summary, you don't have to, but unless your project is "a new web framework", you're probably better off using one of the existing ones instead.
Framework? Heck, you don't even need a web server if you're using Python, you can make one in around three lines of code.
As to the why:
The most plausible thing I can think of is that Perl and PHP were developed before the notion of using frameworks for web apps became popular. Hence, the "old" way of doing things has stuck around in those cultures. Ruby and Python became popular after frameworks became popular, hence they developed together. If your language has a good framework (or more than one) that's well supported by the community, there's not much reason to try to write a Web App without one.
A framework isn't necessary per se, but it can certainly speed development and help you write "better" code. In PHP, there are definitely frameworks that get used like CakePHP, and in Perl there are many as well like Mason and Catalyst.
The frameworks aren't necessary. However, a lot of developers think frameworks ease development by automating a lot of things. For example, Django will create a production-ready backend for you based on your database structure. It also has lets you incorporate various plugins if you choose. I don't know too much about Rails or Perl frameworks, but PHP frameworks such as Zend, Symfony, Code Igniter, CakePHP, etc are used widely.
Where I work at we rolled our own PHP framework.
Are these frameworks necessary?
No. They, like any 'framework', are simply for speeding up development time and making the programmer's job easier.
If not, is there a reason why these languages are often used within a framework, while Perl and PHP are not?
PHP and Perl were popular languages for building web sites well before the idea of using frameworks was. Frameworks like Rails are what gave Ruby it's following. I'm not sure that Python or Ruby were that common as web languages before they were backed by frameworks.
These days, even PHP/Perl web developement should be backed by a framework (of which there are now many).
By no means are those development frameworks required. But as with most development environments, your productivity will increase exponentially if you have a supported framework to reference and build your applications on. It also decreases the training needed to bring others up to speed on your applications if they already have a core understanding of the framework that you use.
For python, the answer is No you don't have to. You can write python directly behind your web server very easily, take a look at mod_python for how to do it.
A lot of people like frameworks because they supply a lot of the boilerplate code in a reliable form so you don't have to write it yourself. But, like any code project, you should choose the tools and frameworks on their merit for your problem.
You can certainly write CGI scripts in either language and do things "raw".
The frameworks (ideally) save the trouble of writing a pile of code for things that other people have already handled (session handling, etc.).
The decision probably comes down to what you need to do. If the framework has the features you need, why not use it. If the framework is going to require extensive modifications, it might be easier to roll your own stuff. Or check out a different framework.
The python library has numerous modules for doing cgi, parsing html, cookies, WSGI, etc:
http://docs.python.org/library/index.html
PHP has a lot of frameworks. Probably more then most. In Ruby most use Rails so thats what you hear, and Django for Python is mentioned more then not.
But with PHP you have many to choose from.
List of web application frameworks
Any language that can "print" can be used to generate web pages, but frameworks handle a lot of the HTML generation for you. They let you concentrate more on the content and less on the details of coding the raw HTML.