[jack9]

I can't think of one (other than FB) where this is preferable over some form of REST (just go back to calling it HTTP actions or HTTP). Tying services together makes for more problems (as coupling often does), not less.

The very first point is either disingenuous or outright ignorant. "Gone is the mess of relying on an ever expanding set of predefined REST endpoints", moving that to the server logic is not "better". The number of code paths hasn't been reduced, just placed deeper in the execution path. How many months does it take the average developer to learn deep paths are worse than shallow ones?

Next, your result caching needs to be inserted in other places. As result caching is no longer at a predictable location AND mixed with other cached values (if you just keep caching everything at the request level) which makes splitting work more difficult.

Most of the sentences are restatements or vague assertions, until you get to the "type system". This part is where the "idea" stops seeming all that original, since webservices (in aggregate) define an application query system. You can always define what your APIs return so the "asking for the results you want" as if it's new, is a just a misunderstanding of how webservices work NOW.

Finally we get to the actual selling point. Ad-hoc results. Typically, if your using services, you know the common operations that need to be combined and probably, so do the vendors (sometimes that's yourself). Popping out a new endpoint for combined data (see: https://client.cdn77.com/support/api/version/2.0/data#Purge All vs Purge) or adding a GraphQL-esque query param is not all that unusual, except in edge cases where you have a giant graph database. This is not the common case.

[justinclift]

The GitHub post about GraphQL indicates it's more efficient (on the server) when people use GraphQL instead of REST.

To me - looking to provide API access from a new project soon - that sounds like a good potential win.