Intro to Graph APIs

https://zapier.com/engineering/graph-apis/

by brian_cooksey • 9 years ago

91 25 9 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• 9 years ago

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

bretthopper• 9 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.

yen2232• 9 years ago

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

jondubois2• 9 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.

zzbzq• 9 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.

jondubois2• 9 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• 9 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• 9 years ago

Here is an example how to do realtime subscriptions with GraphQL

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

jbpetersen• 9 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• 9 years ago

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

recursive• 9 years ago

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

bmn__• 9 years ago

GraphQL is an incremental improvement over REST.

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

askvictor• 9 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"

samtoday• 9 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/

frik• 9 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.

emilsedgh2• 9 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• 9 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• 9 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• 9 years ago

Why is it more than 7 queries?

emilsedgh2• 9 years ago

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

Intro to Graph APIs

Related Stories