Thanks for the input! I’m not sure if there’s much I can say, given your disappointment seems to go down as deep as technologies that we’ve chosen, which isn’t something that’s actionable for us right now. I appreciate the insight, and if you’re ever up for it I would love to sit down and figure out what parts of our GraphQL API were enough to steer you away from the tech.
The introduction of any new technology definitely has a learning curve, which naturally creates friction when trying to adopt it. Our goal with GraphQL was not to be ‘hype’, but to provide a richer option for people to integrate against and provide new access methods beyond a single-resource REST API. Of course, it’s not going to meet every use case - when I drop down to cURL to make a quick query to GitHub, I still use our REST v3 API because I think it’s much better suited for things like that - which is why it’s not going away any time soon! On the other hand, you have the capability today of executing GraphQL queries that would take hundreds to thousands of individual REST calls, all in one 3 second request!
One of the reasons that we decided to adopt GraphQL was to avoid exactly the problem you mentioned: not creating another query language. Instead, we adopted a language that has been in production at companies like Facebook and Twitter for a good amount of time and has a rapidly growing community that’s created fantastic integrations and tooling around it. While it would be cool to create an ANSI SQL API to GitHub, that approach would likely be even more complex than a GraphQL implementation and come with a large set of problems that would be completely unique to GitHub.
It saddens me that we weren’t able to win you over with our new GraphQL API, and I hope that at some point you’ll give it another chance - I know it’s got some awesome capabilities, and I’d be more than happy to take a look at anything you need that we’re missing!