4 ms·

I guess in theory we could take a gql query like: query { user { first_name last_name } settings { debug paid } }

I guess in theory we could take a gql query like: query { user { first_name last_name } settings { debug paid } } could be translated into: GET /user/first_name GET /user/last_name GET /settings/debug GET /settings/paid And you could represent any gql query as a multiplexed http2 call. And you could then have the server use a persistent user scoped dataloader (or some other shared cache) to resolve all that data and respond to each of those queries. That's roughly an isomorphism between graphql and http2.

dajonker 7y ago
With one notable difference that the multiple GET requests can be (much) more easily cached than the GraphQL example.
sourcesmith 7y ago
In reality, that would be GET /user GET settings; the cost for the unneeded associated fields at that point of time is typically not significant for many backends as they stored in aggregate and text based responses compress well. If the data is not particular dynamic then you can cache the entire representation deriving a future benefit. Graph base queries tend to lend themselves to adhoc query patterns and I would be concerned about unpredictable patterns of loading. If the backend store is distributed then graph QL looks more attractive to me. If the datastore stores related attributes in aggregate there seems to be little benefit since different parts of an adhoc graph would different levels of 'cachability'. I have found an application for GraphQL in storing soft-defined triggers or other criteria on data.
nikkwong 7y ago
I suppose so. As someone who hasn't used GraphQL, isn't most of the appeal in GraphQL attributable to the fact that you don't have to manually write all these rest endpoints? In that way, I don't see GraphQL as irrelevant in light of HTTP2; the goal of the former being to take the overhead of writing endpoints off the backend team.

dajonker 7y ago

With one notable difference that the multiple GET requests can be (much) more easily cached than the GraphQL example.

sourcesmith 7y ago

In reality, that would be GET /user GET settings; the cost for the unneeded associated fields at that point of time is typically not significant for many backends as they stored in aggregate and text based responses compress well. If the data is not particular dynamic then you can cache the entire representation deriving a future benefit. Graph base queries tend to lend themselves to adhoc query patterns and I would be concerned about unpredictable patterns of loading. If the backend store is distributed then graph QL looks more attractive to me. If the datastore stores related attributes in aggregate there seems to be little benefit since different parts of an adhoc graph would different levels of 'cachability'. I have found an application for GraphQL in storing soft-defined triggers or other criteria on data.

nikkwong 7y ago

I suppose so. As someone who hasn't used GraphQL, isn't most of the appeal in GraphQL attributable to the fact that you don't have to manually write all these rest endpoints? In that way, I don't see GraphQL as irrelevant in light of HTTP2; the goal of the former being to take the overhead of writing endpoints off the backend team.