Postgraphql: A GraphQL schema created by reflection over a PostgreSQL schema | Hacker News Reader

Postgraphql: A GraphQL schema created by reflection over a PostgreSQL schema

github.com

217 pointscraigkerstiens24 comments

People might also be interested in Postgrest. Postgrest is an open-source project that creates a REST api based on a Postgres schema: https://github.com/begriffs/postgrest

It ain't GraphQL, and I don't understand GraphQL enough to note functional differences. Postgrest made it extremely easy to serve a more-than-sufficient api for my db though.

Definitely, PostgREST is an awesome project and definitely an inspiration for PostGraphQL. I gave the project credit in the README: https://github.com/calebmer/postgraphql#thanks

Great work on PostGraphQL.

Easy to setup, and well documented.

I'm going to start doing some load testing, I'll let you know what I find.

Postgrest is one of the most underrated projects out right now for automating api creation. Easy to work with, reliable, and scalable. It motivated me to learn Haskell also.

I really like the README in this project. I had a lot of questions (especially going to production and extending GraphQL myself) which are answered in the README. https://github.com/calebmer/postgraphql/blob/master/README.m...

But I don't know how to do it yet.

With WAMP and crossbar.io, you can already directly query in SQL you PostGres db from the browser. So this does not give you real advanstages over existing solutions.

The real benefit of GraphQL is that it unifies stuff:

- several queries can be masqued as one; - several storages systems can be queried in one shot; - the cache layer can be integrated in the graphql server; - queries can actually no type in any backend and just run code; - the query doesn't hold logic, just data mapping. - queries can propagate events, trigger tasks, etc.

The graphql server is nice because it's an intermediary layer, separating your data manipulation from the rest of the logic in your system.

You definitly don't want you DB to be the only one doing the authentification/permissions nowaday, unless you want to script it to do social auth, OAuth, connect to a ldap, etc.

And you do want to be able to graphql your way into stuff that are not into your db.

AGPL license is probably a non-starter for many/most potential use cases of crossbar.io.

GPLv2 was fine. But GPLv3 can make one look for alternatives. AGPL will cause many to simply lose all interest. I suspect GPLv3 is why we see so much MIT/BSD/Apache licensed software these days.

Very good point.

Where I can see this being really useful is for people trying out GraphQL for the first time. If you already know PostgreSQL, throwing this interface over it means the GraphQL bit is the only thing you've got to learn.

Indeed, I haven't though about that.

Agreed. My impression is that using this in a real project is almost a non-starter, but it's a good way for trying out GraphQL.

What? Why would it be a "non-starter"? It is made for being used for real, and people use it for real.

It's just that many people want to be able to use the software by doing modifications to it for their secret sauce. And they don't want to share the sauce. AGPL forces you to share it, even if you don't distribute the software: as long as you make a service with your modified version, you are legally entitled to share the modifications.

Of course, it's almost impossible to prove IRL, but still, a lot of corporations have problems with that. They want the free open source project to make them earn money, no price to pay.

Did you reply to the wrong post? It isn't AGPL, and corporations have nothing to do with what I said.

Because there are many benefits to using GraphQL that aren't supported if you explicitly tie the schema to the data source - one of them being the relative ease of supporting out-of-date clients. Another being the ease of supporting multiple data sources in the same schema, like Elasticsearch, Redis, etc (though I guess you can have PostgreSQL talk to those data sources instead).

My use of "real project" was perhaps a little unfair. What I mean is that as soon as you go beyond the simplest requirements of a GraphQL server, a solution like this is going to present more problems than it solves.

This looks amazing. I can't wait to dig into the internals and play around.

I've been thinking about a "Postgres-first" application design for some time, where a thin GraqhQL/REST layer sits on top, and most of the business logic lives in Postgres directly, or operates as a triggered async function (eg; AWS Lambda).

You might want to look at the serverless project.

You can setup a cloudfront distribution postgres rds.

Use Postgraphql/postgrest as stateless api layer. I would use a docker container and ECS to keep it horizontally scalable.

Then just whip together a client app that consumes your api.

https://github.com/serverless/serverless

I know this is simple, but when you need to publish multiple versions of an API on a db, I don't see this as useful. It will only get in the way down the road of defining a strong API.

What you end up with in something like this is the data model is the API. Why not just expose SQL directly at that point? (Rhetorical question)

The psql client returns a format web client cannot consume. The translation to JSON for example is really important. The reverse (speak SQL) is also quite true. That being said, my observation (and my own project too is guilty of this) is that a lot of ORM users simply map their model almost 1-1 in the API response. An example would be returning a Book the json basically contains every column as keys.

This sounds awesome: I really wish something like this were available for Vitess (http://vitess.io/) so that it could also be automatically sharded.

Curious how response depth is usually handled in something like this, especially if recursion comes into play. Don't know much yet about Relay.

There's no unbounded recursion in GraphQL: response depth equals query depth.

You have to specify the depth in the query by explicitly describing each level. There's no way to specify infinite depth (by design). https://github.com/facebook/graphql/issues/91

If you really wanted to get all the comments on a post, for example, you would have to have a flattened "comments" listing (but each comment could have an id and parent id, which you could use to re-build the nested structure on the client)

Facebook handles malicious queries by setting a list of permitted queries. I want to get this implemented soon at the server layer, check out my PR here: https://github.com/graphql/express-graphql/pull/77

Reply on news.ycombinator.com