Intro to Graph APIs | Hacker News Reader

Intro to Graph APIs

zapier.com

91 pointsbrian_cooksey25 comments

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?

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.

`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.

Why is it more than 7 queries?

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

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?

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.

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.

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.

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.

Those aren't trivial problems to solve in a traditional REST framework either. In GraphQL, having one whole query delivered upfront means the server can do some clever query-planning and app-level caching to efficiently fetch its required data. REST endpoints can't do that, since the queries will be spread across multiple network requests.

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...

Here is an example how to do realtime subscriptions with GraphQL

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

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.

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

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

> GraphQL is an incremental improvement over REST.

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

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"
    ]}}
  }

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

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.

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.

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

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

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/

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.

Reply on news.ycombinator.com