Matt Juszczak wrote:
The term "REST" is an early predictor for project failure a year or
two down the road. More than once I've been the guy who cleans up
the mess after somebody ignorantly blunders into using "REST" for
something that it's not appropriate for.
Well, we didn't go that route. We had three choices: Put database
logic inside the webserver code base, put it in the database, or put
it somewhere in the middle. We decided on putting it in the database,
which ties us to using MySQL, but allows us to write a lot more front
ends a lot easier.
The architecture where "multiple processes communicate with a shared
database" gets less credit than it deserves. In your case I think
there's no reason you can't write your batch scripts in PHP: pretty
commonly I write command line scripts that run as cron jobs... In that
situation, you can use
http://php.net/manual/en/function.pcntl-fork.php
to fork the same way you would in Perl. I tend to do long-running
tasks as cron jobs that are scheduled to run for a certain time (maybe 4
minutes) and that get respawned every so often (say 5 minutes.) You do
need some logic to prevent them from getting stacked up when things go
wrong, but this works pretty well.
BTW, I've got no problem with an RPC-based architecture; there
really are two ways REST is a danger sign: (i) 80% of the time it's a
sign that people don't know what they're talking about... They really
want to say "not SOAP" and they've never heard of POX (plain old XML) or
POJ (plain old JSON.) In those cases it's easy to set people straight.
The 20% of people (ii) who know what REST are actively dangerous.
There are quite a few problems w/ REST, but the biggest is the lack
of transactional semantics. It's easy to write a RPC that "transfers
money from bank account A to bank account B" and handles all the
transactional stuff on the server side. Now, it's certainly possible
to build a REST system that posts a transfer slip, and the posting of
the transfer slip causes the transfer to happen transactionally; that
could be part of a great document-based architecture, but I've yet to
see somebody using REST in the field think that far ahead. I suppose
you could use REST together with a distributed transaction mechanism,
but that's really asking for trouble.
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
