GraphQL: A data query language

Post by TheMakeA » Tue, Sep 15, 2015, 1:15 AM UTC

Geee wrote: post #28

catshirt wrote: post #24

Earlier quoted context omitted.

responsibility of the client, no? to dictate how many results to return.

Ugh.. My comment was meant in the Relay thread, but anyway, it sounds like Relay/GraphQL is designed to not fetch anything that isn't actually rendered. In my own SPA apps, I very frequently over-fetch to reduce latency. I was hoping there would be a nice compatible way to manage this use case. I'm not too familiar how this works, but maybe it's enough to query the additional data in parent component or somewhere and…

Post by TheMakeA » Tue, Sep 15, 2015, 1:20 AM UTC

dschafer wrote: post #16

aaroninsf wrote: post #7

Why mirror the structure, but not syntactic details, of JSON (or YML) in the pretty printing? It's true that we've passed peak colon as a culture, and need to start reimagining life in a post-colonial way, but...

GraphQL queries are hierarchical so that the response mirrors the structure of the query. We found that there were needs of the query (query parameters and directives, for example) that didn't feel ideally represented in JSON, which is why we have a different syntax. We've got a reference lexer and parser in JS at https://github.com/graphql/graphql-js/tree/master/src/langua... , and we have a parser in C++ with C and…

Post by 15155 » Tue, Sep 15, 2015, 1:30 AM UTC

dschafer wrote: post #20

jaked89 wrote: post #14

What about inequality operators (>, >=, What about complex predicates (and, or)? The language seems rather limited.

When building out a GraphQL schema, the schema developer chooses which functionality to expose to the client. So rather than having the client do operations or predicates directly, the server declares what functionality is available, and might expose functionality that ordinarily would have used operators or predicates. For example, we might have the following query on Facebook's GraphQL schema: { user(id: 4) { follo…

Post by nathancahill » Tue, Sep 15, 2015, 2:02 AM UTC

tiglionabbit wrote: post #36

nathancahill wrote: post #22

Earlier quoted context omitted.

Interesting. I wonder how that plays with caching. Most caches ignore POST requests.

You don't want to use the browser's cache here. You can cache the properties in a more granular way yourself. Relay will do that for you.

Post by cbsmith » Tue, Sep 15, 2015, 2:12 AM UTC

TheMakeA wrote: post #30

Every time there's a new post about GraphQL, I become even more concerned that "GraphQL" was the wrong name to use publicly. It seems like most people assume it's just another combination of two buzzwords, Graph and QL, and incorrectly pattern match it. In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead. It's not a storage layer. It's not really a query languag…

  In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead.
  
  It's not a storage layer. It's not really a query language. It's an alternative way to define an API that more closely matches the typical mental and product domains than REST.