GraphQL has nothing to do with SQL and a lot to do with addressing problems associated with choppy nature of REST in practice.<p>In essence, GraphQL query is a grocery list of stuff you want. Response is a grocery bag of what you wanted.<p>From REST perspective, GraphQL is a union of multiple REST query URLs presented as JSON hierarchy, turning each path fragment into a nested object.
What's I'm missing from all the GraphQL examples seen out there is some kind of interaction with database.<p>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?
In some ways GraphQL reminds me of Microsoft's OData.<p>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?
Way I understand GraphQL is not as a replacement to SQL, otherwise you get hopelessly lost at implementing it.<p>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.<p>Above is simple explanation I would try to implement GraphQL. Mutators are a different story I have not thought about.
How do you get performance and not lots of nested queries out of GraphQL?<p>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.