Moose is a fantastic object framework. The trouble is that, taken together with its dependencies, it’s very big. Our profiling indicates that on our platform, simply loading Moose will incur a 5-6 second overhead on non-persistent CGI application scripts. That’s just not acceptable for these one-off applications.
By contrast, when we’re using a persistent process system (such as FCGI), this startup overhead is eliminated (or rather, only incurred once), and all is well. The problem we have is that we can’t guarantee that all of our code will always run under a persistent process.
We investigated using Mouse as a feature-limited drop-in-replacement for Moose, but as it turns out (as mentioned in this answer) that’s not a viable option. Any libraries we write to work with Moose will fail to work with Mouse in subtle but important ways. And we really don’t want to fork all of our modules so that we can support both Moose in a persistent environment and Mouse for “vanilla” CGI.
Given that, we have the following options:
- Fork our in-house modules to work with either Moose or Mouse, as appropriate. (Yuck!)
- Only develop our modules for FCGI/Moose. Don’t support “vanilla” CGI anymore. If we have to write scripts that aren’t persistent, they won’t be able to leverage our in-house modules.
- Don’t use either Moose or Mouse, but some other object framework.
Which option is best? We are leaning towards 2 right now, and we’ll just suck it up if we have to get something running as a vanilla CGI. How about other frameworks? Is there anything more lightweight we should be looking at?
My preference would be to drop vanilla CGI support. FCGI hosting is really cheap these days and there’s no reason to pander to vanilla CGI (IMO) because it just reinforces the opinion that Perl is slow. But if you can’t avoid it then you can use something like Object::Tiny. But if you need Roles, constraints, meta-programming and all the other loveliness that Moose provides, you’re out of luck unless you drop vanilla CGI.