Postgrest: GraphQL revisited

[ruslantalpa]

I am quite interested in the new (frontend) technologies coming out of FB and GraphQL + Relay + React is a very powerful combination.

I want to propose to steer the capabilities of postgresql to be isomorphic to a graphql server.
After the addition of &select with it's nested capabilities, the "read part" has the same power as a GQL server

compare this

{
  projects (active: true) {
    id,
    name,
    client {
        id,
        name
    },
    tasks (completed: false) {
        id,
        name
    }
  }
}

to this

/projects?select=id,name,client(id,name),tasks(id,name)&active=eq.true&tasks.completed=eq.false

The other lacking part is "mutations", in GQL you can say "make this mutation then return this data".
In postgrest you can say "Prefer:return=representation", we could extend it to something like "return=id,name,client(id) ..."

With this additional capability, i think (more or less) postgresql can act as a graphql server (has the core capabilities).
Now the main question is, how to make postgresql understand a graphql query.
The first approach would be to code it in through a parser which would not be too hard to do but i hope it would be unnecessary.

When looking at relay (frontend client that talks to a graphql server) i noticed a part of code called RelayNetworkLayer.
I think it provides the capabilities to intercept a GQL query and translate it into a postgrest request.

Please look at this video to get a sense of why i'm advocating graphql support.

PS: Did someone get the reference of the image? :)

[calebmer]

Playing the long game, nice :relaxed:

I'm struggling to understand why we want GraphQL. I haven't yet watched the video (but I will when I have time) is there any way you can briefly describe the benefits (1)? Also, why support it server side and not client side (2)? And with all this talk about PostgREST layers (#306, #260) why not use a proxy to translate GraphQL into the syntax PostgREST supports (3)?

I'm going to be upfront, I'm a little biased against React and friends (especially with the whole death to CSS stuff). Facebook seems to be completely moving away from the rest of the tech industry and standards committies with their software, which I am not confident will last in the long term. (Bias no. 2 I joined this project hoping to push things in the JSON-LD direction :blush:)

All that said, if we can add GraphQL support for free (read: no breaking changes, doesn't change the project's vision, bugs are isolated), why not?

[ruslantalpa]

I did not say support the the graphql necessarily in postgrest, ideally a graphql request would be translated to postgresql somewhere else (client or proxy), but the capabilities of postgrest need to be isomorphic to a graphql server.
@calebmer i don't get the (death to CSS), how is react killing css?

[ireverent]

This is funny, me and another developer who are using react were looking into Flow and GraphQL and thought how awesome it would be to be able to use it easily with postgrest.

[ruslantalpa]

Flow is cool but relay is amasing :)

[calebmer]

@ruslantalpa React is not directly killing CSS, but it is definitely encouraging the death of authoring CSS. A large contingent of React's community is arguing for this: overview, an implementation.

Also, what is the point of this issue if ideally this is in an independent layer?

[joaoportela]

@calebmer It seems to me that the intention is to make postgrest isomorphic with GraphQL, making it possible to add the layer on top. Am I right?

[ruslantalpa]

Yes, that is right

[calebmer]

What other functionality is needed? Just mutation?

[begriffs]

Limits and cursors for child nodes are required too.

[ruslantalpa]

cursors, hard part :(

[calebmer]

Question, what exactly is required for each thing? Mutations, limits, and cursors; but specifically mutations. More specifically, does that mean we can introduce a camelCase option? (old habits die hard)

[ruslantalpa]

mutations means the POST/PATHC/PUT/DELETE requests

[staminaloops]

Guys, this is one of those cases where you have to give it five minutes. This re-thinking of good practices coming from the React ecosystem has change (for better, really better) my results and workflow as a frontend developer (and yes, I still use CSS/sass see here why) . Ember and Angular are going in that direction too.

Really love the idea of postgrest, very well done, and like @ruslantalpa said, it almost match GraphQL in the "read only" part. :smile:
In GraphQL, mutations are the way to allow GraphQL clients(or external parties) to modify your dataset. I suggest anyone interested in GraphQL to see https://learngraphql.com/
For me, one of the main benefits its this:

The GraphQL engine parses queries into an AST representation and given this tree and the schema, it traverses the nodes evaluating an executor which uses the definitions from the schema to retrieve objects, and access fields on the retrieved objects (for example, a field may map to a property on the object, or to a function that computes derived data or itself performs an arbitrary call to another service).

This is made performant by a combination of two things: pervasive caching (so that if the same data is requested multiple times at different places in the tree, the actual data is fetched only once) and extensive use of asynchronous primitives (async/await) which enable us to effectively parallelize and batch operations.

There is a proof of concept of psql <-> GraphQL here: GraphpostgresQL -- a graph interface to relational data, but still, only a proof of concept.

It would be great to see this implemented here, it would be huge, but maybe its not part of your roadmap, and thats ok, because what you are building here is great too :smile:

[calebmer]

I was just about to ask about the status on this question @staminaloops and I saw your comment 😊

What have we decided about this? Is GraphQL support going to be an external library or baked into PostgREST? It might be best to use the node tools provided by Facebook.

As a side note, I've recently dived headfirst into React for better or worse and I'm interested in trying GraphQL.

[ruslantalpa]

@staminaloops
The v3 branch already contains mutations with select capabilities (https://github.com/ruslantalpa/postgrest/tree/v3) i.e. when doing insert/update, if you supply the &select parameter, the result will be shaped just like in a normal get request

Things that are missing

• Inline conditions like users (id: 10) (They can be specified as id=eq.10 but it would be nice to have them in &select)
• Renaming of nodes like "john: users ..." (quite useful when you want to something like "projects { client: clients {...}}")
• Fragments (mainly a convenience thing)
• Variables (mainly a convenience thing)

If first two are implemented, and we change select=_,clients(_) to select=_,clients{_} (and it would not be very hard, nor will it break old code) then with the addition of some clever nginx config we might have a working graphql server.

[calebmer]

@ruslantalpa @staminaloops why not just use the node GraphQL project to do GraphQL parsing for you? All that we need to do to hook it up is implement some resolve functions.

[ruslantalpa]

@calebmer That's not true (referring to implement some resolvers), things are more complicated that that :)

[ruslantalpa]

Not sure how to explain it but if you implement a resolver that fetches data from postgrest for every endpoint/node then you would basically end up executing a query for every item (through posrgrest) instead of a single big query that fetches all the data at once.
graphql-js (especially it's "executor" part) is an implementation specific to data that lives inside memory/arrays/objects. It is very inefficient if the backend is a DB (basically generate a query for every single item, not type)

[calebmer]

@ruslantalpa ok I get it. Then why not just have a SQL implementation in a stored procedure callable as an rpc? (Just playing devils advocate)

[thomasfr]

I personally like GraphQL very much and i would love to see this implemented like PostgREST does with PostgreSQL and REST. And although it would be nice to have such a feature built-in in PostgREST i am not 100% sure if postgrest is the right place. Not everyone likes it, or maybe the project does not need something like graphql.
So, maybe a kind of "plugin" or "hook" in postgrest would be better!? But does postgrest provide this possibilty? This system could decide which plugin is responsible for generating the request, via the requested / accepted mime-type as described also in the JSON-LD feature (#343). Therefore such features could then be implemented as plugins and they would be completly optional.

[ruslantalpa]

Update:
The latest release 0.3.0.2 contains shaping of mutations responses.
This makes postgrest mostly compatible/isomorphic to graphql specs. I would say the only important part missing is the ability to rename nodes but that is not very hard to implement.
Anybody interested in wrighting up some lua+nginx that translates a graphql request to postgrest request?

[wanghaisheng]

@ruslantalpa

Anybody interested in wrighting up some lua+nginx that translates a graphql request to postgrest request?
that`s interesting. i am interested in openresty and pogtgrest both.

[calebmer]

I think the easiest way we do this is actually with a node server which could use the GraphQL parse method to get a GraphQL AST and transform it into one or more PostgREST requests (reminds me of babel).

If someone would like to start this, I would be willing to test it in my app.

[badri]

@calebmer just curious. Can a combination of GraphpostgreSQL and Postgrest RPCs do the job? What are the shortcomings in this approach?

[calebmer]

It's true, that would be a valid approach, but I fear for the implementation quality as the project isn't endorsed by Facebook and the code hasn't been updated in months. Maybe if the project used libgraphqlparser I'd think differently.