Re: [OT] cutting out the middleperl

On 27/03/07, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On 22 Mar 2007 14:58:15 -0700, Kev <kevinjamesfield(at)gmail(dot)com> wrote:
> > Hi everyone,
> >
> > I'm still in the design phase of a project. I was just wondering if
> > anyone has any thoughts or experience on the idea of cutting the P out
> > of the LAMP (or in my case, WAMP for now) stack. What I mean is
> > having
> > everything encapsulated into sql (or plpgsql or plperl where needed)
> > functions stored in the pgsql server, and have Apache communicate with
> > pgsql via a tiny C program that pretty much just checks whether the
> > incoming function is on the allowed list and has the proper data
> > types,
> > then passes it straight in. Any errors are logged as potential
> > security
> > breaches.
> >
> > I'm really new to mod_perl too, so another question would be if this
> > would be much faster than a simple perl script that did the same
> > thing.
> >
> > I ask this because I realize I need to carefully check data coming
> > into
> > pgsql functions as well as at the client end. Why maintain a bunch of
> > scripts with names similar to the functions they're calling and all
> > performing similar checks anyway?
> >
> > I was kinda salivating at the thought of how fast things would be if
> > you
> > cut out the A as well, by using a Flash applet to give socket access
> > to
> > JavaScript. But then I guess you have to make your pgsql server
> > itself
> > publicly accessible on some port. Is that just asking for trouble?
> >
> > I appreciate any comments or thoughts anyone might have on this.
>
> IMO, I think 'thin middleware' approach is a great way to design
> applications...so you are right on the money. The web server. IMO,
> should be mostly concerned about rendering html. I don't think
> eliminating the middleware is really practical. While you could use a
> thick-client javascript framework like GWT and write your queries in
> javascript (getting data back via json), I don't think it's really
> possible to secure this properly without killing the 'ease of
> implementation' factor.
>
> Then again, it's no worse then your typical old school visual basic or
> delphi in-house application so common in the 90's. I really miss the
> simplicity of Delphi.
>

Strangely the in-house application is often still the better way to
go. The web can make everything 3 times more complicated than it needs
to be. Toolkits like GWT help this but you still need to write
"middleware" even when you can trust the trust the end user. Hence
most places still use in-house applications except the VB or Delphi
gets replaced with Ruby or Python. Here we use C++ and Qt but thats
another story.
The web should still be used for mass market apps and heavy
communication apps and not standard desktop answers. (Unless you
particularly like writing everything twice)
The secret is to use the right tool for the right job, and not try and
find the does everything spanner that fits all nuts and also undoes
screws too. Its never going to work in every case. Unfortunately some
people like this idea.

Peter.