|
in reply to Re^8: Alternative to CGI.pm
in thread Alternative to CGI.pm
I'm going to go out on a limb and say that there is an architectural issue there. I've worked on multiple CGI projects and we start to wonder what we're doing wrong if a page takes more than 5-6s to run, starting from click to beginning to draw ... with the caveat of network latency not counting in that time. That's for the normal pages, exceptions like running reports don't count as that could require pulling GB of data out of the DB.
The last place I worked doing CGI, we had nearly 300 hits per second during peak times and CGI kept up just fine, including auth/sessions and DB connections+retrievals and processing. Sure, you could feel the site slowing a little at that rate, but it wasn't painful. I'll agree that modern hardware removes a number of the old issues of CGI.
Of course, your app may have special needs, lots of back-end calculations or whatever, that prevent quick take some user input to the server, process, return the result.
Part of the reason I'm not overly keene on Mojo is that it pulls in over 30K lines of Perl last I looked (including parts of Moo and who knows what else). Yes, I know that CGI.pm isn't a lightweight, but changing to CGI::Simple or something like it isn't all that bad and yet gets me the basics of what I need to get the job done. I think a lot of this boils down to the choice of do you want to 'roll your own' or use someone else's code?
There are so many frameworks out there that I'm very choosy when to learn a new one and it has to really wow me before I'll spend the time on it. I've yet to find a good wow-factor for the PSGI stuff; if I ever do, I'll look at switching.
|
Re^10: Alternative to CGI.pm
by Your Mother (Archbishop) on Mar 29, 2017 at 03:19 UTC
|
There are several architectural issues in our code that could be improved; mostly because it was built to CGI.pm era standards which are a hodge-podge, string-manipulation oriented mess. There are dozens of issues in our code that cannot be improved. The average page loads something like 30 subpage/resources, many of which are dynamic because of deep, and legally mandated, permission issues. Lots of heavy data image processing, a dozen encrypted IO and CPU intensive dæmons running all day, indexing and reindexing millions of records all the time, and six or seven different code bases and toolsets glued together. If you suggested customer facing compile on demand code, CGI.pm or otherwise, was viable at work at Google or Amazon or any company with big, deep webapps…
Our code base has north of 30K lines of in-house code—the main code lib file alone has 17K and the main JS file has 10ishK—before a single module or C, Perl, or Java lib is loaded. With persistent execution (and enough RAM to throw at the problem) it’s a non-issue.
I wanted to outline why an MVC framework is better than home-rolled CGI.pm for a couple days. It’s too deep to go into except superficially. It boils down to a professional web application can be written in BASIC, the code library isn’t the issue. You can build a mansion with bronze age tools every bit as well as modern tools, there is no contractor in the world who would voluntarily do so and it would cost a thousand times more. The amount of work, the cost of revisions and changes, the risk of regressions, the ease of testing, the flexibility of deployment, the ease of additions like Oauth or model changes, the free development and support from the community. These things matter more than the actual application. In a framework, 90% of the support details are done for you and tested and continuously improved by dozens if not hundreds of other developers and teams. I am a CGI.pm expert. I’ve written a couple thousand CGIs with it going back to the late 90s; including Intranet stuff at Amazon that was used by thousands of employees. locate .cgi | ack -v COPY | wc -l on this new computer, a decade since I’ve written a CGI for professional reasons, still gives 218. I am not a CGI detractor. I am a webdev supporter.
I would like you consider the hubris necessary to believe that home-rolled code is going to be better, on any level, than what two decades of iterative development, deployment, and testing across several languages by the best developers in each can produce.
| [reply]
[d/l] |
|
|
It sounds like your app has some special needs. I also understand "history" influencing the design that exists today; it's something we fight here and the improvement never comes as fast as we'd like.
> I would like you consider the hubris necessary to believe that home-rolled code is going to be better, on any level, than what two decades of iterative development, deployment, and testing across several languages by the best developers in each can produce.
You obviously have enough experience to know that the answer to "best" is "it depends on the situation". It also sounds like you probably have the experience, like I do, to have scars from frameworks that promise so much and almost do what you want yet don't quite fit your needs.
Perhaps the system I work on is "simplistic" enough that I don't have the same needs you do. The vast majority of our code sits in PM and SQL files that understand how to do the business logic that drives our system (the Model). The "GUI handling" parts are actually quite small in comparison, so the "Controller" aspects are simple and don't require all that much effort. Auth/Sessions are the only hard parts for us and they aren't hard given a few modules from CPAN.
It may be a misunderstanding on my part, so feel free to educate me and anyone else who reads this, but how does a PSGI framework help me when the vast majority of our code is to support the Model part that that would have to be the same no matter what framework I use? The majority of my time in bringing up a new page is spent on (largest time sinks first) the Model part, then the Javascript for the dynamic pieces, then a page template, and finally the Controller (CGI and calls to the Model). The first 3 are framework independent (meaning I'd have to do them regardless of the chosen framework). For us, the last piece which is framework dependent is quite small.
Please note, I'm not saying the PSGI framework couldn't be used or even helpful to us, but when you have a fully working system, then any large architectural change requires a pretty high "wow factor" to convince us that we need to learn a new framework and change. That's where I'm coming from. Perhaps we're in a niche, but the "CGI framework" we have works well for us. Performance isn't an issue either.
If I was doing a brand new system from scratch, I'd seriously consider a good framework that made my life easier, but I've yet to find an article/something that communicates to me concrete whats & whys that the various frameworks have which will make my life significantly easier. I fully recognize that's most likely a failure on my part and why I ask for pointers to places that have good explanations. I also fully recognize that what I probably really need to see is not some simple tutorials, but a fully working medium-sized system based on a PSGI framework. One of these days I'll go look for such a beast on Github and see what I find and if that helps me understand.
| [reply] |
Re^10: Alternative to CGI.pm
by Anonymous Monk on Mar 28, 2017 at 23:56 UTC
|
Part of the reason I'm not overly keene on Mojo is that it pulls in over 30K lines of Perl last I looked (including parts of Moo and who knows what else).
The cpan knows :) at this moment Mojo depends only on these four modules, only the first of which is not core
IO::Socket::IP
JSON::PP
Pod::Simple
Time::Local
| [reply] |
|
|
Apparently my memory had gone bad. :) Thank you for the correction. I'll stop blaming Mojo for that. Next time I have to install a new version of Perl here I'll pay more attention to dependencies.
| [reply] |
|
|
