It’s thankfully just Perl-only, and mostly a sane interface to do database queries. It could happen that not just the web front-end will use the functions in it, but other, related applications as well — though right now, it’s a web-only thing. Speaks both JSON and XML (oh the pain, that…), the front end is mostly RESTful and clean, and the reason we haven’t jumped the PSGI boat yet is simply the lack of familiarity with the new stuff + lack of time. I do have it in my mind to make a fork of it and do it the Plack way (or maybe even use Dancer to give me the routing-fu), but for the amount of (internal) traffic this is going to receive, our usual Apache + FCGI combo is more than enough.
Yeah, legacy stuff. Hard to switch from things you already have configured way better than you’d do with something new in the next half year…
So back to AcmeAPI.pm. I had had a rather short time frame to work on it, and when I’m in such a situation, I tend to keep things in as few files as possible. Wrote extensive tests to make sure things happen the way they are supposed to happen, but kept the file organisation issue to a minimum. So it’s one monolith (and another thing that does (de)serialisation for XML and JSON — to/from the same structure the API functions expect it.
RPC::Any that you mentioned in the other post — nice catch, it is an RPC, more than an API. Weird naming.
So as the pm itself is not legacy (just some of the technologies involved are), and it’s only yet used by the frontend CGI, I can freely do anything to the backend, as long as I keep the frontend’s interface and the functionality (same URL with same data doing the same things) the same.
Also, we do use VCS, we have switched to Mercurial from SVN a good while ago and we definitely use it all the time. No worries there.
In reply to Re^2: Package/module organisation question
by Ralesk
in thread Package/module organisation question
by Ralesk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |