GraphQL defines the query language, but uses simple HTTP as the transport. It's not like like redis or mysql - those use custom protocols and so require special clients to use them. GraphQL backends are like Elasticsearch backends - you access them by hitting the exposed HTTP endpoint with your query in plain text. You could do this with any HTTP client library in any language, or even with curl.

Thats true, but in a typed, structured language, you generally build some kind of data structure to deserialize responses into. With REST endpoints, each response can be translated to a specific predefined object in a client library. GraphQL seems to, by design, ignore this kind of usage in favor of the "heterogenus untyped dictionary responses"... do I really have to write custom data types for every single different query?

I think get this now - with SOAP/RPC/REST we can establish the interaction contract by explicitly defining inputs and outputs. With that contract, we can draw clearly defined system boundaries, give better assurances to the developer that they are doing the right thing, and improve testing.

You're right - in the scale of app-level problems, GraphQL is just a low-level protocol. It requires language-specific libs to address these higher-level problems (provide interfaces, structs, query typing, etc). As a very basic example, programatically building a GraphQL query is unnecessary complex outside of JS because many languages don't yet have a QueryBuilder for the GraphQL syntax. There are some community efforts, but as of yet no heavy corporate players to drive GraphQL-specific dev (e.g. like Pivotal/Sensio/Sencha did for their respective fields).

I found that link before, but aren't those all backends?

You can write the server in any language, and you can also write the client in any language. As a point of comparison, consider SQL databases such as MySQL or Oracle or MongoDB. There are clients written in dozens of different languages.