A first GraphQL Server(medium.com)
medium.com
A first GraphQL Server
https://medium.com/@clayallsopp/your-first-graphql-server-3c766ab4f0a2
23 comments
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!"
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!"
Hi I'm Nick Schrock one of the GraphQL developers at Facebook.
While GraphQL certainly shares some attributes with OData, we believe it is substantially different enough from Data that we aren't simply repeating the same mistakes.
There are a number of differences, but two in particular are striking.
1) Is that the GraphQL language is built with product developers in mind. This is a subjective/qualitative judgement, but we believe that it's just a much more elegant language, and that it is a more powerful platform for tool-building. We hope to prove this out in the coming months as both we and the community build tooling atop the language and the introspection system. 2) GraphQL is more constrained. A OData service has to support a huge number of operations that make it more of a generic querying service, rather than a highly structured way to expose application logic. We agree with you that often cover too much and without adequate performance guarantees.
In terms of complexity on the server side, I think this is a really legitimate question. Our answer is that although there is complexity, it is generally incurred on a much smaller set of core and tool developers. The average product developer who will just need to expose a capability via a GraphQL type and then consume it on the client will not find the system overly complex.
While GraphQL certainly shares some attributes with OData, we believe it is substantially different enough from Data that we aren't simply repeating the same mistakes.
There are a number of differences, but two in particular are striking.
1) Is that the GraphQL language is built with product developers in mind. This is a subjective/qualitative judgement, but we believe that it's just a much more elegant language, and that it is a more powerful platform for tool-building. We hope to prove this out in the coming months as both we and the community build tooling atop the language and the introspection system. 2) GraphQL is more constrained. A OData service has to support a huge number of operations that make it more of a generic querying service, rather than a highly structured way to expose application logic. We agree with you that often cover too much and without adequate performance guarantees.
In terms of complexity on the server side, I think this is a really legitimate question. Our answer is that although there is complexity, it is generally incurred on a much smaller set of core and tool developers. The average product developer who will just need to expose a capability via a GraphQL type and then consume it on the client will not find the system overly complex.
A bit late so you might not read this, but I really like your response and it's going to make me take a deeper look at GraphQL. Thanks for the writeup!
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.
This sounds like you think more developers pay attention to what Facebook do than Microsoft. If that's the case then you are a long way off. A really long way.
This sounds like you think more developers pay attention to what Facebook do than Microsoft. If that's the case then you are a long way off. A really long way.
Not necessarily more developers, but different developers, I suspect.
Interesting comparison. I didn't remember ODATA having a way to specify queries but I guess I was wrong: http://www.odata.org/getting-started/basic-tutorial/#select
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?
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?
Here's my toy attempt at implementing it https://gist.github.com/jawr/b4c585b69b8e83255513
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.
How does resolve deal with asynchronous calls? The name almost suggests that you might be able to return a promise?
Yes, you can return a Promise in resolve(). I believe it's mentioned in the first half of this talk: https://www.youtube.com/watch?v=gY48GW87Feo
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.
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.
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.
GraphQL has nothing to do with SQL and a lot to do with addressing problems associated with choppy nature of REST in practice.
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.
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.
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.
GraphQL is a query language. It's protocol-independent. It just so happens that HTTP POST is a convenient way to deliver queries. Instead of using an HTTP endpoint, you could just as correctly implement GraphQL directly over TCP, or messaging queues, or whatever you want.
True, but when implementing GraphQL on top of webserver (like Express.js in article), correct HTTP methods should be adopted - GET for querying, POST for mutations. I don't see any harm in doing that.
Sure, but the manor it is going to be used in real life is HTTP POST, 99% of the time. This is the use-case it is trying to solve, after all.
I think given the current state of the spec that's pretty accurate. However we really view GraphQL as the way that front-ends/client specify their data requirements. One way of fulfilling that is to dispatch the queries to the server as is. However if you view this as an API to data, which can include client software, this can get a lot more interesting, and allows you to use different transports, messaging protocols, etc
For example on iOS we used GraphQL to transition our persistence from Core Data to a propriety (client) storage engine.
For example on iOS we used GraphQL to transition our persistence from Core Data to a propriety (client) storage engine.
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.
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.
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?