
Intro to Graph APIs - brian_cooksey
https://zapier.com/engineering/graph-apis/
======
emilsedgh
I'm really interested to know how server side API's internally handle
overreaching problems and performance.

Client side developers in my current workplace always ask for huge nested
objects. We're having a tough time regarding performance as responses are
sometimes 6-7 levels of nested objects.

That means a ton of database queries. How does everybody else manage this?

~~~
aaronblohowiak
Why is it more than 7 queries?

~~~
emilsedgh
If its a collection of 100 items it would be 700 queries.

~~~
chao-
Wouldn't it only be 7?

First query gets the first 100 items, the second query gets the nested
associations for those 100 (assuming you couldn't batch it into the first
query), the third gets the nested associations for the second's, and so forth.
One query for each entity category?

------
jondubois
GraphQL is an incremental improvement over REST. The next big thing will be
REST over WebSockets with single-field granularity and real-time subscriptions
for field value changes.

~~~
zzbzq
That might look more like graphQL over websockets with realtimes updates.
Somebody told me about an already-existing GraphQL with real-time push updates
ready-made for integrating with the front-end framework, wish I knew the name
of whatever this was, but maybe somebody will chime in.

Not sure how anything is RESTful anymore once it's over websockets. The whole
point of REST is it's a perfection of HTTP, and the whole point of HTTP is
it's the slowest, most awkward networking protocol ever devised made to pander
to the browser's flaccid capabilities.

~~~
jondubois
One problem with GraphQL is that there can some overlap between the results of
different queries so it can be wasteful. Also access control is more difficult
because a GraphQL query might reference multiple different data types which
have different access control rules (a user may only be allowed to see part of
the query result) - So it makes access control a lot more complicated.

~~~
lwansbrough
Facebook has a solution for over-fetching, which they call dataloader.

As for the access control problem: it's easily solved with existing features
of GraphQL. GraphQL exposes a user context which can be referenced on a per-
property basis and thus used to check the permissions of the user.

------
thelazydogsback
Why doesn't GraphQL just define semantics over what is JSON syntactically so
existing tools and parsers are sufficient? It's already so close to JSON, why
use parens and strings containing emedded JSON? E.g., instead of:

    
    
      {
        "query": "repository(owner:\"zapier\", name:\"transformer\") {
          id
          description
        }"
     }
    

use something like:

    
    
      {
        "query": {target: "repository", owner:"zapier", name:"transformer",  [
          "id",
          "description"
        ]}}
      }

~~~
geonnave
Maybe they want to be, to some extent, serialization-format independent?

~~~
bretthopper
That's correct. See [https://facebook.github.io/graphql/#sec-Serialization-
Format](https://facebook.github.io/graphql/#sec-Serialization-Format).

> GraphQL does not require a specific serialization format. However, clients
> should use a serialization format that supports the major primitives in the
> GraphQL response.

JSON is preferred, but not required.

~~~
thelazydogsback
The section of the document you refer to is regarding the _response_ , not the
query-language itself. From the document: "A GraphQL document is defined as a
syntactic grammar" \-- therefore GraphGL has a (one) preferred syntactic
embodiment. The document goes on (in A BNF style) to define the syntax of the
language. The language defined here is very close, but not quite, JSON - if it
_were_ JSON, they could have defined the semantics of GraphQL based on its
structure (which could be surfaced also in XML, etc.) rather than defining any
surface/syntactic form at all. If this domain specific language had a huge
value-add over plain JSON, it would be another matter, but the notational
convenience is small given the all the tooling that you lose by not having be
in a standard format.

------
askvictor
I'm wondering if Microsoft is regretting it's decision to name it's
overarching, pretty much bog standard REST API as "Graph API"

~~~
frik
They have other bigger problems, they are still trapped in Stone Age with XML
everwhere (like SOAP), and not nice XML but very obscure usage and memory
dumps inside of XML and what not - very ugly mess, often on purpose to keep
their formats hard to implement in competitive products.

