I did not followed recent GitHub news closely. Is GraphQL a new thing at GitHub? And do you think GitHub integration benefits from this?
All new features at GitHub are now developed with GraphQL first which means integrators will have access to the same API that we built the feature on once it ships.
If you want to learn more, one of our engineers just spoke at GraphQL Europe yesterday detailing our experiences with GraphQL thus far, here are his slides: https://speakerdeck.com/bswinnerton/launching-githubs-public...
In graphQL there's one resource and you query it to tell you what you want.
https://blog.runscope.com/posts/you-might-not-need-graphql
tl;dr: maybe you want OData, JSON-API, or one of the many other standards or practices that solve this simple problem as their super-set of functionality on top of the networking principles of REST.
Using GraphQL for this alone is rather nuclear, as you gain a lot with GraphQL but lose other stuff.
https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overv...
The REST philosophy is so conceptually big that it's useless for actually building a system; what I meant by 'in practice' is that REST in practice is 'how do I stuff what I want into the http verbs and make it seem plausibly like state transfer' and that's an exercise that I can't see myself doing 'for purity' again. (in a simple app that actually is just asking about and updating state, sure, it's fine. But when you have to make ten queries for different records because you can't ask the server to join things for you dynamically, it's less fun.)
(edit: especially when you need the results to be an atomic picture of the underlying data, gathered in a transaction. Do I invent a GET resource for every tuple of values I might want to query directly? Or do I stop blindly following an architecture and do the practical thing and implement real queries? A: Always the latter.)
The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]:
/users/123?fields=name,email,work.name,work.address
user({ "id": 123 }) {
name,
email,
work {
name,
address
}
}
GraphQL is a form of RPC, it's not REST.
It's a tradeoff that makes sense for Facebook. It allows them to make changes to their API without needing to version it. And they can take the hit of more requests hitting their server. For most apps though, I think the tradeoff is probably not a great one to choose.
Nitpick but REST is not a spec to begin with. It's a set of ideas. There is absolutely no normative REST spec. Developers as of today are still debating what REST is, for better or worse. GraphQL IS a spec, like SOAP, XML-RPC ...