Everything around GraphQL seems to be assuming the client is user-operated such as a web or smartphone app, with the rare scenario of a node.js service being su

Everything around GraphQL seems to be assuming the client is user-operated such as a web or smartphone app, with the rare scenario of a node.js service being such a rarity that it takes some research to figure out if there's even a solution for it. Try to do anything beyond the basics with, for example, golang. This is completely fine and understandable given the use-cases that motivated it, and the community that's been driving it. But it's not a hammer for all nails. Reading the OP post, it's obvious they have a very narrow perspective when the one thing they compare it to is "REST". The nice thing with HTTP/JSON, and IMO a major factor in it's ubiquity, is that it's an OK (while not always ideal) solution to implement towards for pretty much any use-case. Performant and stable HTTP clients and JSON parsers/formatters are even part of a lot of standard libraries, and straight-forward to implement should you need to. The benefits of GraphQL compromise this. protobufs in general and grpc specifically are a much better solution for many scenarios, due to some trade-offs being different. A lot of the issues and concerns brought up by other commenters here is "leaky abstractions are gonna leak". I'm sorry, but there's no free lunch. IMO it's a bit delusional to claim with certainty that "There will be a future where you can query any system in the world using GraphQL". I'm not even sure I want o live in that future if it means 1) I have to support it and 2) it comes at cost of other protocols.