Intro to Graph APIs

91 points by brian_cooksey 8 years ago | 25 comments

emilsedgh 8 years ago |

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?

denimnerd 8 years ago | |

you need to denormalize your database so you can just query for those particular objects without a bunch of joins. Put a limit on nesting, but honestly 6-7 levels doesn't sound that bad.

cel1ne 8 years ago | |

`jsonb` functions in Postgresql can build nested objects in a single select statement. Combine that with proper joins and functional indices and there shouldn't be a problem.

aaronblohowiak 8 years ago | |

Why is it more than 7 queries?

emilsedgh 8 years ago | | |

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

jondubois 8 years ago |

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.

jbpetersen 8 years ago | |

Having played around with building exactly that, the conclusion I came to is that REST is nice for not having the additional setup step of establishing a websocket connection as well as having the considerably better support for simultaneous http requests over rebuilding that part of the networking stack once again and layering it on top of everything else.

For real-time subscriptions though, websockets (pardon my grammar) are wonderful. Hence why all the above will probably be ignored as they become a trend and people at large learn the sensible limits of what to use them for.

martindale 8 years ago | | |

Neat! I'd love to see your work, as I'm working on something very similar right now. Maybe we can collaborate?

zzbzq 8 years ago | |

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 8 years ago | | |

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.

hn_throwaway_99 8 years ago | | |

Here is what's on the horizon: https://dev-blog.apollodata.com/new-features-in-graphql-batc...

Subscriptions already exist: https://dev-blog.apollodata.com/graphql-subscriptions-in-apo...

x5t23 8 years ago | | |

Here is an example how to do realtime subscriptions with GraphQL

https://www.graph.cool/docs/tutorials/worldchat-subscription...

bmn__ 8 years ago | |

> GraphQL is an incremental improvement over REST.

No, it's a huge step backwards into RPC.

recursive 8 years ago | |

The more things change, they more they stay the same. Last time, this was called OData.

thelazydogsback 8 years ago |

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 8 years ago | |

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

bretthopper 8 years ago | | |

That's correct. See 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.

yen223 8 years ago | |

GraphQL queries supports other things like fragments, which don't map very well to JSON.

askvictor 8 years ago |

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 8 years ago | |

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.

samtoday 8 years ago | |

Facebook has a lot of things called the "Open Graph" [1]; most of which pre-date GraphQL. Some aren't even APIs as such.

[1] eg. http://ogp.me/