4 ms·

I did not followed recent GitHub news closely. Is GraphQL a new thing at GitHub? And do you think GitHub integration benefits from this?

dewski 9y ago
We've been developing on GraphQL internally for the past year, releasing our public preview on September 14th of last year: https://githubengineering.com/the-github-graphql-api/ https://githubengineering.com/the-github-graphql-api/ 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-graphql-api https://speakerdeck.com/bswinnerton/launching-githubs-public...
m12k 9y ago
GraphQL is a method of creating APIs for consumption by e.g. JavaScript apps or mobile apps that is gaining popularity at the moment. So it can be seen as a successor to REST. It gives you a pretty easy query language to specify which data on which objects you are interested in and that data is then fetched for you. An example could be a React app where each component specifies which data it needs to work on, and then when a page is loaded, all of the rendered component's queries are merged into a single query that fetches all the data in one go.
- nailer 9y ago
  The main thing vs REST is that it fixes the 'overlapping data in resources' issue. Want a timeline of tweets? Well you'll also want avatars to display, and you probably don't want that in a separate resource (because of multiple requests), so both /tweets and /users/userid will give you avatar details. It's a bit messy. In graphQL there's one resource and you query it to tell you what you want.
  - philstu 9y ago
    Hey! I cover that a bit ni a followup blog post :) https://blog.runscope.com/posts/you-might-not-need-graphql 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.
    - nailer 9y ago
      What do you lose? I actually use REST ATM but interested in GraphQL for my next project.
- mpetrovich 9y ago
  REST and GraphQL are two completely different things, and one is not a replacement for the other. REST is an architectural concept, whereas GraphQL is a query language spec. https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/ https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overv...
  - ajkjk 9y ago
    That's true in theory, but in practice REST is a (limiting) spec for the kinds of verbs you're allowed to use between systems, and graphQL is a significant and much needed expansion of that.
    - boubiyeah 9y ago
      You should read about REST then :)
      - ajkjk 9y ago
        I have, a lot, and when I could only GET kinds of hierarchical data instead of lumping nested queries, I turned to graphQL (or a, er, homegrown subset of it - it had just been announced) to fill in the gaps. It turns out that most software doesn't, really, care about asking for or updating 'state' per se, and the amount of awkward munging you have to do interpret every kind of query as 'asking about state' is, in my opinion, largely pointless. 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.)
m-j-fox 9y ago
GraphQL sounds like a cool thing I should be using already. Now let me scroll down to find out why it's a dumpster fire I should avoid at all costs.
- deleted 9y ago
  [deleted]

dewski 9y ago

We've been developing on GraphQL internally for the past year, releasing our public preview on September 14th of last year: https://githubengineering.com/the-github-graphql-api/ https://githubengineering.com/the-github-graphql-api/ 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-graphql-api https://speakerdeck.com/bswinnerton/launching-githubs-public...

m12k 9y ago

GraphQL is a method of creating APIs for consumption by e.g. JavaScript apps or mobile apps that is gaining popularity at the moment. So it can be seen as a successor to REST. It gives you a pretty easy query language to specify which data on which objects you are interested in and that data is then fetched for you. An example could be a React app where each component specifies which data it needs to work on, and then when a page is loaded, all of the rendered component's queries are merged into a single query that fetches all the data in one go.

nailer 9y ago
The main thing vs REST is that it fixes the 'overlapping data in resources' issue. Want a timeline of tweets? Well you'll also want avatars to display, and you probably don't want that in a separate resource (because of multiple requests), so both /tweets and /users/userid will give you avatar details. It's a bit messy. In graphQL there's one resource and you query it to tell you what you want.
- philstu 9y ago
  Hey! I cover that a bit ni a followup blog post :) https://blog.runscope.com/posts/you-might-not-need-graphql 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.
  - nailer 9y ago
    What do you lose? I actually use REST ATM but interested in GraphQL for my next project.
mpetrovich 9y ago
REST and GraphQL are two completely different things, and one is not a replacement for the other. REST is an architectural concept, whereas GraphQL is a query language spec. https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/ https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overv...
- ajkjk 9y ago
  That's true in theory, but in practice REST is a (limiting) spec for the kinds of verbs you're allowed to use between systems, and graphQL is a significant and much needed expansion of that.
  - boubiyeah 9y ago
    You should read about REST then :)
    - ajkjk 9y ago
      I have, a lot, and when I could only GET kinds of hierarchical data instead of lumping nested queries, I turned to graphQL (or a, er, homegrown subset of it - it had just been announced) to fill in the gaps. It turns out that most software doesn't, really, care about asking for or updating 'state' per se, and the amount of awkward munging you have to do interpret every kind of query as 'asking about state' is, in my opinion, largely pointless. 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.)

m-j-fox 9y ago

GraphQL sounds like a cool thing I should be using already. Now let me scroll down to find out why it's a dumpster fire I should avoid at all costs.

deleted 9y ago
[deleted]