Re: Using Postgresql as application server

On Mon, Aug 15, 2011 at 9:50 AM, Andreas Joseph Krogh
<andreak(at)officenet(dot)no> wrote:
> På mandag 15. august 2011 kl 16:36:23 skrev du:
>> On Sat, Aug 13, 2011 at 2:30 PM, Andreas Joseph Krogh
>> <andreak(at)officenet(dot)no> wrote:
>> > No, PG has never, and will never, act as an application-server.
>>
>> Why in the world not?  Now, it may or may not be a good idea but there
>> is no technical constraint that prevents postgresql from being used in
>> this fashion. I think it's a fine idea.
>>
>> Postgresql has certain features, in particular being able to implement
>> functions in any language, that make it uniquely well suited among its
>> peers to act as a application server platform.  Having a
>> quasi-functional front end to your middeware procedural code is very
>> powerful as is having direct access to a local data store for caching
>> and spooling purposes.  So powerful that I would argue that if
>> properly supported by tools it would be superior to many of the more
>> classic stacks in use today.  I could go down the list of reasons why
>> that's the case -- tight coupling with data, performance, emphasis on
>> transactional coding, etc.   There are downsides too, but those could
>> be mitigated with some thought and work.
>>
>> Postgres is not just a database -- it's a language hosting platform if
>> you want to use it as such.  Now, you can continue to do things as
>> you've always done (database 'here', code 'here', web server 'here'),
>> but why discourage people from trying out different things?
>>
>> merlin
>
> Sorry if I stepped on any toes here. But seriously - by my definition of app-server PG is not suited at all. I strongly would discourage anyone from using any RDBMS as an app-server. *IMO* it makes development, testing, separation-of-consern, debugging and re-deployment a nightmare.
>
> PG has a lot of nice DB-features and I use it every day, but as an app-server - no way.

Nobody's toes are getting stepped on. Constructive debate gets people
talking and puts the issues on the table. Your complaints are pretty
non-specific (development is a 'nightmare'...why?). This topic
reminds me a lot of the 'is putting logic in functions a good idea?'
debate which tends to bring out strong opinions which are light on
substance. As I've said many times this debate gets really
interesting in the specific case of PostgreSQL because the database is
so extensible with good abstractions in the right places.

An application server from my point of view is just a server that sits
between the UI (typically a browser these days) and the database.
This server manages various temporary structures like application
state and data spools coming from the 'persistence later' (the
database). Due to heavy emphasis on the importance of putting most
code into this layer from companies like IBM and Microsoft, we've seen
an explosion of tools and libraries that can be hooked in here so
that, if you choose to do so, you can drive the entire application
stack such that the database and the browser are just appendages of
this system. This path is rich, well traveled, and boring. But are
we things really being done in the right way? I obviously don't think
so...in fact I think the typical corporate IT programming dept is a
total disaster.

Many programmers, especially those who really get SQL and the
relational model tend to resist programming in this fashion because
they feel that it's over-complex, verbose (especially in java-land),
and brittle. SQL provides a lot of strong guarantees that are
relatively easy for even a junior programmer to take advantage of like
serializability of action and automatic rollback to a known state due
to an unhandled error. Programming around the lack of these features
could charitably be described as creating a strong justification for
the excellent debugging tools you are mentioning.

merlin