V8 Engine in PostgreSQL
code.google.com
code.google.com
I don't see why one would code DB procedures in JS though. Are there really many cases where a dba/designer's best known and favorite lang is JS? I doubt that.
"The controversy over Node is that it implies developers from the client are piercing into the server. A domain typically full of people that came up from the OS layer. Those people are asking does it really make sense to write servers in a historically client language? (One that as you mention is inherently far slower than historical server languages). People who only know or love that client language have been given a whole new freedom and ability - surely their answer is yes. Why wouldn't it be?"
Very well put. And now they can put logic in the DB too. Bravo!
As you said, this just adds JS as yet another language to write stored procedures for PostgreSQL. There's no real need to disparage choice.
You have a form, you enter data, the data is somehow aggregated and presented to you in some other form or the data is sent off to some other service that then processes the data in some other way.
Removing a layer between the JS frontend and the DB just simplifies the whole stack: if postgres can do something like
(select * from employees).to_json
var record = {"empId": 2, "empName": "Franz"}
insert into employees (emp_id, emp_name) values (record.empId, record.empName);
SELECT query_to_json('select x as b, x * 2 as c from generate_series(1,3) x',false);
I can't find the link now, but the reverse (insert, update from json) I remember also to be possible.
Are you suggesting you allow the client-side JS app to call directly against the Postgres DB or is there another approach you had in mind?
One thing to keep in mind about PostgreSQL is you can do a lot of traditional middleware tasks (including message queues) in the database back-end with transactional control. These can even be hooked into other applications Remember, you can put a lot of what would otherwise go in a middleware layer in the database itself, especially with features in PostgreSQL like LISTEN/NOTIFY.
There are some limitations of this approach, but in general, I have found it ideal, but it requires thinking about your database differently. Instead of a data store on the bottom of the stack, you have an intelligent data storage and queuing system in the center of your environment.
It means there are choices between the traditional ones of putting everything in the database or in the middleware.
Almost directly. The JS frontend calls something like mod_libpq¹, or a very simple node.js "proxy". Something that just gets incoming http requests, executes stored procedures and sends back the response. A reverse proxy between the JS client and Postgres. That proxy can be very generic and reused between applications. All logic would live in the db.