
Postgraphql: A GraphQL schema created by reflection over a PostgreSQL schema - craigkerstiens
https://github.com/calebmer/postgraphql
======
bageldaughter
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](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.

~~~
calebmer
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](https://github.com/calebmer/postgraphql#thanks)

~~~
gjolund
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.

------
therealmarv
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...](https://github.com/calebmer/postgraphql/blob/master/README.md)

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

------
sametmax
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.

~~~
regularfry
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.

~~~
andrewingram
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.

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

~~~
sametmax
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.

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

------
rattray
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).

~~~
gjolund
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](https://github.com/serverless/serverless)

------
bluejekyll
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)

~~~
yeukhon
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.

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

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

~~~
calebmer
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](https://github.com/graphql/express-graphql/pull/77)

