Nick Schrock here, one of the GraphQL co-creators. I agree with a lot of the criticism in terms of the difficulty of implementing GraphQL backends. I think there's a big opportunity for folks to build vertically integrated toolkits that deal with N+1 issues, integrate DataLoader natively and so forth. Good versions of these would deal with a lot of issues described here in greenfield GraphQL backends. I talked about this at the GraphQL Europe keynote last month (https://www.youtube.com/watch?v=zMa8rfXI6MM).
Current greenfield implements are typically stacked on ORMs like Django and RoR, and the impedance mismatch is real. Personally I abide by the dictum that ORMS are "Vietnam of computer programming" and should be avoided at all costs for anything that will grow beyond a small app. GraphQL was not originally implemented on top of an ORM, but instead an object model built on key-value + edge store internal to Facebook.
In terms of other criticisms in this thread:
1) Exceptions: The default behavior in graphql-js (mimicked in other language implementations) of swallowing native exceptions by default was probably a mistake in hindsight. Whenever I've played with GraphQL using different toolsets the first thing I change is to add a wrapper function which checks for errors and then rethrows the initial exception that caused the GraphQL error for use in testing and CI/CD contexts.
2. Caching: Personally I've always been confused about the concern with leveraging HTTP-level caching. While a clever hack, with any real app with any sort of even mildly dynamic behavior you don't want to do this. Staleness will be interpreted, rightly, as bugs by your users. If you want to replicate the behavior the most straightforward way would be to use persisted queries (described here https://blog.apollographql.com/persisted-graphql-queries-wit...) combined with HTTP GETs. With persisted queries you can encode the entire request in the query string, which should get you the HTTP-level caching you want.
3. Docs: Quite confused about this one. While particular implementations of GraphQL can be problematic the documentation of the core language (which I am not responsible for) is superb. See http://graphql.org/ and https://www.howtographql.com/.
My largest criticism of GraphQL is that it doesnt go far enough. That is to say that I want my components to declare their data dependencies, but not all data comes from a server. Some data is computed, other data comes from different servers, and some other data is locally generated. For example, facebook has some user information that I want to add to my User object; in my case, theres no reason for the component to know that its data is actually coming from multiple sources but I have no simple way of coding that.
Another issue: there currently are a lot of servers that are REST and it would be really nice if there were ways of incorporating them in the GraphQL schema. One of the most useful features to add here would be ways of linking separate REST objects to each other in the GraphQL schema. This would help adoption quite a bit.
I'd check out Apollo for these use cases. They allow a client GraphQL schema to be sourced from a bunch of different places, including (I believe) local-only state, REST APIs, and others. See https://www.apollographql.com/docs/link/links/rest.html
Great job. Awesome to see all the focus on documentation and conceptual explanations. Clear messaging and spreading understanding are just as important as the tech.
This is a super exciting release and I'm really excited to see the community go in this direction, specifically the ability to add more sophisticated, custom capabilities to the server. GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics.
It is also surreal to see GraphQL go from the first prototype system I wrote five years ago to where it is today. I'm so impressed with the players in the community and its humbling to see so many people take the ecosystem to new heights.
Congratulations to the whole Graphcool team on this awesome milestone!
Thank you so much for your support and most important of all, your great work on GraphQL. Without your (and others') great ideas, Graphcool (and many other tools & services) wouldn't exist today.
Hi I'm Nick Schrock and I actually came up with the name. Graph in this context means social graph or more generally the conceptual graph of data in your application, which you can query. It doesn't mean that it is a formalized graph database in any sort of way, nor does it seek to be.
I understand the name causes a bit of confusion but the ship has kind of sailed on this one :-) I think people will get used to it if/when it becomes a widely known name.
Ironically, the "query language" part also misses the mark, and I think that part confuses people more (as in that RethinkDB discussion).
GraphQL is closer to what we call a protocol; it has minimal syntax, a kind of data model, and it can only be used for declaring requests. You can't implement anything in GraphQL: absolutely all of its expressions are implementation-provided — contrast with, say, SQL, which, being an actual query language, defines operators, arithmetic expressions, mutations, etc. A defining quality of a protocol is that it's a medium through which clients can talk to multiple black-box implementations, which is exactly what GraphQL is.
I like GraphQL, but I wish you'd thought through the name before you started to publish about it. If you'd called it something like Extensible API Protocol, nobody would have batted an eyelid.
I'm sure you're right because you have the power of facebook behind you but yeah the name is problematic. I agree with lobster_johnson in that it's not a "query language" either, it's more like an analogue of JSON.
Virtually every graph database vendor now gets requests that they implement GraphQL, because from the name it sounds like it fits but in reality it's totally unrelated.
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.
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.
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.
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.
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!
