GraphQL so far to me just seems like a way to facilitate freedom to front-end engineering in terms of not begin dependent on the back-end when query-ing; I image that when back- and front-end teams are separate that it can be frustrating to front-enders to wait for the api developers to have made something available to them.

At the same time I can see that it works in the other way around; back-end engineers don't have to keep up with changing query requirements from the front-end team.

The same is suggested in the article and confirmed in the response to the only comment:

"The point is that most APIs end up having to support lots of different client requirements all at the same time... and then those requirements change... and then they change again. You don't want to have "fix" your API every time this happens. GraphQL would support a lot of these differing requirements with no changes to the server code at all."

"You don't want to have "fix" your API every time this happens." I don't see why not. Requirements change thus code changes, its not a big deal.

The sacrifice you make with this 'not having to change the server side code' is that you are never able to change the server side code again without risking that you take away functionality that is somehow used by some client somewhere. I say 'somehow' because with REST there is usually an endpoint that is either used or not, but with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API.

It all depends who you are though. For Github it is probably a good idea to provide a GraphQL API as this freedom in the front-end will make adoption of their API and thus their service more likely. If you are a normal company and you are the only consumer of your API I highly question the added benefit.

I might be wrong though, so if anyone could point me at some high quality resources on the benefit of GraphQL I am very interested. This article wasn't really that.