Intro to Graph APIs
zapier.com
Intro to Graph APIs
1–10 of 27 posts
Re: Intro to Graph APIs
#2Why 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
}"
}
{
"query": {target: "repository", owner:"zapier", name:"transformer", [
"id",
"description"
]}}
}Re: Intro to Graph APIs
#3Why 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?
Re: Intro to Graph APIs
#4GraphQL 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.
Re: Intro to Graph APIs
#5GraphQL 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.
Re: Intro to Graph APIs
#6GraphQL 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…
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.
Re: Intro to Graph APIs
#7Why 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.
Re: Intro to Graph APIs
#8Earlier 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.
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.
Re: Intro to Graph APIs
#9I'm wondering if Microsoft is regretting it's decision to name it's overarching, pretty much bog standard REST API as "Graph API"
Re: Intro to Graph APIs
#10GraphQL 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.
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.