GraphQL is always POST, no? It's not REST at all. It's not quite RPC either. There's a single handler for all API requests. I don't know if there's a name for this type of thing.
What's I'm missing from all the GraphQL examples seen out there is some kind of interaction with database.
I think I understand how to `resolve` a path into a object. Array of objects should be similar, right? And how do I then describe that object with GraphQL terms? Can `resolve` function of fields get this object passed in?
resolve() takes the current field AST node as one of its arguments. Mappings to more complicated backends will demonstrate use cases of where this is needed. From that field AST you can arbitrarily descend into a ton of information, e.g. the subfields of the current field.
In some ways GraphQL reminds me of Microsoft's OData.
It seems entity-centric though. What would a GraphQL 'mutation' look like that kicked off some process requiring the identity of say 3/4 entities plus some of its own input?
OData was nice on paper and very impractical in reality. I strongly fear that this is just Facebook reinventing it, making the same mistakes, but taking thousands of developers along with them because it's by Facebook and not Microsoft.
The big issue with OData is that it is highly flexible, and as such rather difficult to make cover all cases and keep it performant.
But maybe the real problem was simply that no good OData servers existed, barring the one from MS that tied directly with their ORM and thus your data model.
I really suspect that the flexibility that GraphQL gives immediately translates to complexity on the server side.
It feels like this is ORMs all over, just now between the frontend and the backend instead of the backend and the database. Give it a couple of years and we'll see the REST-version of the "just use plain SQL!" blog posts: "just hand-craft highly specific REST endpoints for exactly what your frontend needs!"
Way I understand GraphQL is not as a replacement to SQL, otherwise you get hopelessly lost at implementing it.
It is in effect a filtering language. You have database view e.g. "user" and you apply it to the given GraphQL and get less fields than the view defined. In this way from server side you have still bunch of functions (the database views) that take in arguments (e.g. User ID) and GraphQL and the view returns the subset of the view.
Above is simple explanation I would try to implement GraphQL. Mutators are a different story I have not thought about.
That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation.
We model mutations as a function that can do arbitrary business logic followed by a client-specified query where the client can query data it knows must be updated in order for the view to reflection the state changes the mutation caused.
How do you get performance and not lots of nested queries out of GraphQL?
GraphQL looks nice in theory, and surely in practice regarding Facebook's storage architecture, I just wish it can be used on smaller project with DB backed data.
[+] [-] donpark|10 years ago|reply
In essence, GraphQL query is a grocery list of stuff you want. Response is a grocery bag of what you wanted.
From REST perspective, GraphQL is a union of multiple REST query URLs presented as JSON hierarchy, turning each path fragment into a nested object.
[+] [-] Touche|10 years ago|reply
[+] [-] silversmith|10 years ago|reply
I think I understand how to `resolve` a path into a object. Array of objects should be similar, right? And how do I then describe that object with GraphQL terms? Can `resolve` function of fields get this object passed in?
[+] [-] jawr|10 years ago|reply
[+] [-] schrockn|10 years ago|reply
[+] [-] jimmcslim|10 years ago|reply
It seems entity-centric though. What would a GraphQL 'mutation' look like that kicked off some process requiring the identity of say 3/4 entities plus some of its own input?
[+] [-] skrebbel|10 years ago|reply
The big issue with OData is that it is highly flexible, and as such rather difficult to make cover all cases and keep it performant.
But maybe the real problem was simply that no good OData servers existed, barring the one from MS that tied directly with their ORM and thus your data model.
I really suspect that the flexibility that GraphQL gives immediately translates to complexity on the server side.
It feels like this is ORMs all over, just now between the frontend and the backend instead of the backend and the database. Give it a couple of years and we'll see the REST-version of the "just use plain SQL!" blog posts: "just hand-craft highly specific REST endpoints for exactly what your frontend needs!"
[+] [-] Touche|10 years ago|reply
[+] [-] Ciantic|10 years ago|reply
It is in effect a filtering language. You have database view e.g. "user" and you apply it to the given GraphQL and get less fields than the view defined. In this way from server side you have still bunch of functions (the database views) that take in arguments (e.g. User ID) and GraphQL and the view returns the subset of the view.
Above is simple explanation I would try to implement GraphQL. Mutators are a different story I have not thought about.
[+] [-] schrockn|10 years ago|reply
We model mutations as a function that can do arbitrary business logic followed by a client-specified query where the client can query data it knows must be updated in order for the view to reflection the state changes the mutation caused.
[+] [-] joesb|10 years ago|reply
GraphQL looks nice in theory, and surely in practice regarding Facebook's storage architecture, I just wish it can be used on smaller project with DB backed data.
[+] [-] Gladdyu|10 years ago|reply
[+] [-] Touche|10 years ago|reply