

PgREST: Node.js in the Database, compatible with MongoLab and Firebase API - audreyt
http://pgre.st/

======
Pxtl
... if I didn't know better I'd assume that headline was spat out by that
Markov chain doodad from the other day.

~~~
audreyt
... it was, in fact, partly inspired by the Markov chain hack.
#BuzzwordBingoButTrue :-)

------
meowface
Looks quite interesting, but I can't help but admit some of these Web 3.0
solutions are getting a bit ridiculous nowadays, especially when it comes to
data storage and processing.

~~~
JonnieCache
_> Web 3.0_

Is that what we're calling this whole 30 lines of javascript, mongo and redis
behind the WAN, dynamic language runtime inside the DB era?

Cool.

EDIT: saying that, some kind of featureful document store implementation
inside postgres seems inevitable. Isn't that all going to be hstore-based
though, what with the new stuff coming in 9.4? I thought the json type was
meant to be kind of a stopgap until the full hstore functionality is finished,
ie. nesting?

See:
[http://obartunov.livejournal.com/175235.html](http://obartunov.livejournal.com/175235.html)

~~~
audreyt
Yup. Nested hstore and JSON are going to be semantically equivalent ("cast"
works both ways), and PgREST will support them equally once 9.4 is released.

PgREST also comes with a shim JSON type for Postgres version 9.1 and earlier,
so the column type implementation is mostly hidden from the user.

~~~
JonnieCache
But hstore will be faster/better because it's a binary representation, right?

~~~
qooleot
JSON will be getting binary representation. Its just a matter of organizing
sponsorship of the project.

~~~
JonnieCache
I assumed everyone would be encouraged to just convert their json columns to
hstore if they wanted the extra speed, being as theyre equivalent. What would
be the reason for funding JSON-as-binary?

~~~
stopthemadness
Traditional databases use complicated indexing and storage structures in part
to minimize the need to examine unrelated data. hstore is better than plain
text for JSON but a scheme closer to the existing PostgreSQL
table/page/row/value hierarchy could be better still.

I'd recommend reading the recent post
[https://news.ycombinator.com/item?id=6813937](https://news.ycombinator.com/item?id=6813937)

~~~
JonnieCache
Of course if I need it to be eye-wateringly fast I wouldn't be using a
document store. I'd use good old relational or something like redis. Often
though you just need a sensible place to put some unimportant schemaless key-
value data without a half dozen extra dynamically created tables or whatever.
EAV makes me very sad.

------
raphinou
I need a simple rest json store, and this could come handy. I'm using
openkeyval right now, but they have a value size limit much too low (which
seems to be a bug).

~~~
willholley
Have you looked at Cloudant ([https://cloudant.com/](https://cloudant.com/))?

------
trumbitta2
So, is this a competitor to couchbase (thinking of kanso and couchapp)?

~~~
audreyt
Yes, we're certainly inspired by Kanso.

PgREST was originally designed for a large, in-production Postgres app (i.e.
Socialtext), so we can get all the model, validation, view & trigger code in
one place, getting the benefits of CouchApps while maintaining the underlying
data layer.

For new projects, the main difference is likely familiarity with the toolchain
(npm+Pg vs Kanso+CouchDB).

~~~
trumbitta2
The word I want to use for this is "refreshing".

Back in the day, I thought Couchapps and Kanso + CouchDB were great and I
hoped they would lead an entire new breed of web applications.

Thank you for making it happen!

------
austinheap
Another killer product from Firebase. They seem to be one of very few startups
in the city that are executing smart and can prove it.

Looking forward to seeing what else the team comes up with since I've already
replaced my MUNI estimation time app with the Firebase SF Muni app :-D

~~~
audreyt
Well, this is more like an open-source (partial) reimplementation of Firebase
so anyone can host it... :-)

Firebase++ for an extremely well-thought-out API, though!

