Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intro to Graph APIs

zapier.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Intro to Graph APIs

#11

Post by thelazydogsback »

bretthopper wrote: post #7
geonnave wrote: post #3

Earlier quoted context omitted.

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.

Re: Intro to Graph APIs

#12

Post by hn_throwaway_99 »

zzbzq wrote: post #5
jondubois wrote: post #4

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 who…

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

Re: Intro to Graph APIs

#13

Post by recursive »

jondubois wrote: post #4

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.

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

Re: Intro to Graph APIs

#14

Post by 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?

Re: Intro to Graph APIs

#15

Post by denimnerd »

emilsedgh wrote: post #14

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.

Re: Intro to Graph APIs

#17

Post by frik »

askvictor wrote: post #9

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

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.

Re: Intro to Graph APIs

#18

Post by cel1ne »

emilsedgh wrote: post #14

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?

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

Re: Intro to Graph APIs

#19

Post by yen223 »

thelazydogsback wrote: post #2

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

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

Re: Intro to Graph APIs

#20

Post by yen223 »

jondubois wrote: post #6
zzbzq wrote: post #5

Earlier quoted context omitted.

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 who…

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.

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.
Post reply on HN