Show HN: GraphQL for Postgres(github.com)
github.com
Show HN: GraphQL for Postgres
https://github.com/solidsnack/GraphpostgresQL
23 comments
That graphql.sql file is pretty amazing and is a great example of the power and flexibility of Postgres. It seems to dynamically generate the graph "database" -- a concept I would have recoiled in fear at the thought of implementing in SQL (well, Postgres SQL and it's niceties). Great work.
This looks great, and I love the idea of GraphQL and declaratively defining the data you need.
I understand this is alpha / proof-of-concept, and this is in no way meant as criticism, also not specific to this implementation, but just trying to figure out something:
What's the security model for GraphQL (at least as intended for javascript clients speaking to a backend)? Can we just pass the GraphQL from the client to the server and execute it? (In this case, directly on the PG database). What kind of security can be built around this?
I understand this is alpha / proof-of-concept, and this is in no way meant as criticism, also not specific to this implementation, but just trying to figure out something:
What's the security model for GraphQL (at least as intended for javascript clients speaking to a backend)? Can we just pass the GraphQL from the client to the server and execute it? (In this case, directly on the PG database). What kind of security can be built around this?
I've been playing with getting a Postgres/GraphQL system working recently too. I decided that the definitions of the "edges" in the schema itself should declare what the user/viewer is capable of fetching via the GraphQL.
I started a very naive implementation of A-Relay-Like-Architecture (Arla) and built todomvc with it[1].... schema.js[2] declares the schema/nodes as well as the 'calls/edges' available for each node, which allows you to limit the visible rows/columns based on the $viewer id.
It's all a bit of an experiment... but I'm liking the GraphQL pattern so far.
[1] https://github.com/kiloe/arla-todomvc [2] https://github.com/kiloe/arla-todomvc/blob/master/schema.js
I started a very naive implementation of A-Relay-Like-Architecture (Arla) and built todomvc with it[1].... schema.js[2] declares the schema/nodes as well as the 'calls/edges' available for each node, which allows you to limit the visible rows/columns based on the $viewer id.
It's all a bit of an experiment... but I'm liking the GraphQL pattern so far.
[1] https://github.com/kiloe/arla-todomvc [2] https://github.com/kiloe/arla-todomvc/blob/master/schema.js
I wonder if one could use a shape-like spec to describe permissions for a user, similar to GraphQL itself?
I would think you'd need some kind of layer over the database for security, I think managing security at the db level would be very clunky at best.
But since the idea of GraphQL handles so much from the logic standpoint, your programming layer can just act as a gatekeeper for access.
That said, Postgres is pretty powerful. Maybe there is an elegant way to do row-level access control.
But since the idea of GraphQL handles so much from the logic standpoint, your programming layer can just act as a gatekeeper for access.
That said, Postgres is pretty powerful. Maybe there is an elegant way to do row-level access control.
>GraphpostgresQL is alpha quality and has undergone neither extensive optimization nor comprehensive testing. To use it for production workloads would needlessly tempt fate.
Ah yes, definitely the Jason I know. ;)
Great work!
Ah yes, definitely the Jason I know. ;)
Great work!
Hm. This looks nice especially now TitanDB is abandoned.
But the lack of updates for json/jsonb data remains a problem. It's really the only significant problem left for using Postgres for almost-everything, but it's a real issue.
But the lack of updates for json/jsonb data remains a problem. It's really the only significant problem left for using Postgres for almost-everything, but it's a real issue.
This just made my day. If I ever meet you I will buy you a beer!
Unless you are underage, in which case that's too bad
Unless you are underage, in which case that's too bad
If you find any issues -- or have some ideas for improvements -- let me know and I'll see what I can do.
I think a v2 release should really be in PLV8. PL/SQL is already there and is probably pretty performant; but it doesn't feel like the best option either from the standpoint of maintainability or community contributions.
I think a v2 release should really be in PLV8. PL/SQL is already there and is probably pretty performant; but it doesn't feel like the best option either from the standpoint of maintainability or community contributions.
Sure, I have a number of projects I'll probably mess around with. Will probably let you know via github if anything goes sour. Or if it's amazing as well!
https://github.com/solidsnack A guy with such an epic Unix beard probably isn't underage. ;)
Though iirc Jason doesn't drink. You might need to buy him coffee instead!
Though iirc Jason doesn't drink. You might need to buy him coffee instead!
Coffee it is!
You should consider adding a LICENSE to your repo.
The license has been changed to distribute GraphpostgresQL under the same terms as Postgres itself: https://github.com/solidsnack/GraphpostgresQL/commit/bec43e3...
This is great. After seeing this in use at React.js Conf I was wondering who would step forward to take this on.
Thanks, and looking forward to seeing where this goes! It's a solid fit for some recent use cases I've run into.
If you could let me know what use cases you have in mind, it would help me to prioritize features and think about what to optimize.
Aside from general usefulness, I'm very interested in "Relay".
https://facebook.github.io/react/blog/2015/02/20/introducing...
https://facebook.github.io/react/blog/2015/02/20/introducing...
This is awesome nicely done man!
This is pretty cool, nice job!