I think given the current state of the spec that's pretty accurate. However we really view GraphQL as the way that front-ends/client specify their data requirements. One way of fulfilling that is to dispatch the queries to the server as is. However if you view this as an API to data, which can include client software, this can get a lot more interesting, and allows you to use different transports, messaging protocols, etc
For example on iOS we used GraphQL to transition our persistence from Core Data to a propriety (client) storage engine.
Comments
Sure, but the manor it is going to be used in real life is HTTP POST, 99% of the time. This is the use-case it is trying to solve, after all.
I think given the current state of the spec that's pretty accurate. However we really view GraphQL as the way that front-ends/client specify their data requirements. One way of fulfilling that is to dispatch the queries to the server as is. However if you view this as an API to data, which can include client software, this can get a lot more interesting, and allows you to use different transports, messaging protocols, etc
For example on iOS we used GraphQL to transition our persistence from Core Data to a propriety (client) storage engine.