At Socialtext, we're working on https://npmjs.org/package/plv8x that installs npm packages into Pg, and maps Node methods directly into Pg functions.
This provides a safe and modular alternative to PL/PgSQL and PL/Perl, and lets us re-use client side models & validators in the database.
https://npmjs.org/package/pgrest builds on this work and offers a subset of MongoLab REST API for an existing Pg database, with the eventual aim of serving JSON APIs directly from the database, cutting out the middleware altogether.
We're also looking at adding Firebase-like ACLs into the mix.
Some setups are pretty heavy on stored procedures. Not too long ago I had a job interview at a company who avoided ORMs and did every complex SQL manipulation that way. So on the client side it was pretty specific what they wanted and instead of writing weird call chains (or mixing code with dozens of lines of SQL), you just did that in the database itself. Don't think they used JavaScript, but if you're already using it in lots of other places, it seems like a natural way to go.
Now I'm actually for polyglot programming and don't think you should do everything with just one tool (especially if its JavaScript), but for stored procedures you're not really losing a lot. This is scripting, after all. And the less said about the DB-"native" PLs, the better. I've still got nightmares about inappropriate use cases of PL/SQL (and hey, I actually like Ada).
Sure, it lets you use JavaScript at every level, from the client side (via in-browser JS) to the server (application side) via Node.js to the backend database (via PL/v8.)
So you don't need different languages for client components, server components, and stored procs / db functions.
The author of PLV8 is also continuing to enrich the functionality with things such as this early github project which aims to add the mongo API and functionality in Postgres - https://github.com/umitanuki/mongres
They use PL/pgSQL to provide a bunch of service interfaces, then have Perl that provides automatic service discovery and object generation. Basically ORM from the inside out.
Comments
can someone give another usage for v8 other than json?
At Socialtext, we're working on https://npmjs.org/package/plv8x that installs npm packages into Pg, and maps Node methods directly into Pg functions.
This provides a safe and modular alternative to PL/PgSQL and PL/Perl, and lets us re-use client side models & validators in the database.
https://npmjs.org/package/pgrest builds on this work and offers a subset of MongoLab REST API for an existing Pg database, with the eventual aim of serving JSON APIs directly from the database, cutting out the middleware altogether.
We're also looking at adding Firebase-like ACLs into the mix.
Currently there's just the NPM doc'n and a bilingual presentation at https://speakerdeck.com/audreyt/pgrest-node-dot-js-in-the-da... —— documentation will appear on http://pgre.st/ as soon as the API solidifies.
Some setups are pretty heavy on stored procedures. Not too long ago I had a job interview at a company who avoided ORMs and did every complex SQL manipulation that way. So on the client side it was pretty specific what they wanted and instead of writing weird call chains (or mixing code with dozens of lines of SQL), you just did that in the database itself. Don't think they used JavaScript, but if you're already using it in lots of other places, it seems like a natural way to go.
Now I'm actually for polyglot programming and don't think you should do everything with just one tool (especially if its JavaScript), but for stored procedures you're not really losing a lot. This is scripting, after all. And the less said about the DB-"native" PLs, the better. I've still got nightmares about inappropriate use cases of PL/SQL (and hey, I actually like Ada).
PL/SQL only looks like Ada, it's not very featuresome.
Bonus fun: IBM DB2 has a PL/SQL front end that compiles to their own bytecode.
Sure, it lets you use JavaScript at every level, from the client side (via in-browser JS) to the server (application side) via Node.js to the backend database (via PL/v8.)
So you don't need different languages for client components, server components, and stored procs / db functions.
The author of PLV8 is also continuing to enrich the functionality with things such as this early github project which aims to add the mongo API and functionality in Postgres - https://github.com/umitanuki/mongres
is there integration like this with elasticsearch? that would be awesome.
There is https://github.com/elasticsearch/elasticsearch-lang-javascri...
Though, it is based on Rhino, not v8 – and it's not sandboxed.
Chris Travers from the LedgerSMB project has done a lot of thinking about this topic on his blog.
http://ledgersmbdev.blogspot.com/
They use PL/pgSQL to provide a bunch of service interfaces, then have Perl that provides automatic service discovery and object generation. Basically ORM from the inside out.