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

GraphQL Working Draft

facebook.github.io

Post reply on HN
Print view View original

21–30 of 71 posts

Re: GraphQL Working Draft

#22

Post by colinramsay »

jaegerpicker wrote: post #19

So, I haven't had enough time to really dig into the spec but it doesn't seem like the language has any kind of insert or update type of feature. Perhaps I just missed it though. But if it doesn't it seems like you would need a pretty large dataset to make this worth it, right? I mean for any kind of a change event you still need to support a standard REST API, as this really only replaces the GET operation. Am I mis…

GraphQL seems to go hand-in-hand with Relay, and there's a talk on mutations in Relay here:

https://speakerdeck.com/laneyk/mutations-in-relay

That might provide the answers you're looking for. It's worth reading all the notes as I think this is the best resource for understanding how React + Relay + GraphQL really works.

You basically use GraphQL with a payload (the data to mutate and the mutation type) to select what to change and what data is returned after the change.

Re: GraphQL Working Draft

#23

Post by dschafer »

jaegerpicker wrote: post #19

So, I haven't had enough time to really dig into the spec but it doesn't seem like the language has any kind of insert or update type of feature. Perhaps I just missed it though. But if it doesn't it seems like you would need a pretty large dataset to make this worth it, right? I mean for any kind of a change event you still need to support a standard REST API, as this really only replaces the GET operation. Am I mis…

GraphQL doesn't prescribe a particular approach to mutations; it allows the server developer to specify what mutations are available. For example, at Facebook we have a storyCreate mutation, and a friendRequestAdd mutation.

Mutations are just top level fields, but with side effects; because they are fields, the client sends up a selection set with the mutation. This allows the client to receive whatever data it needs to refresh, as the response to the mutation.

GraphQL was originally designed for reads, but we added write support to solve the parallel problem we were having with writes: different clients wanted different data back from the server after they performed a write. GraphQL gave us that capability.

Re: GraphQL Working Draft

#24

Post by ZitchDog »

davedx wrote: post #17
applecore wrote: post #13

Finally! It's exciting to see a serious challenger to the cult of REST.

> cult of REST Is this a thing?

Yes, we have regular meetings where we worship a statue of Roy Fielding and debate the merits of HAL over JSON Hyper Schema. Long live HATEOAS!

Re: GraphQL Working Draft

#26

Post by jaegerpicker »

dschafer wrote: post #23
jaegerpicker wrote: post #19

So, I haven't had enough time to really dig into the spec but it doesn't seem like the language has any kind of insert or update type of feature. Perhaps I just missed it though. But if it doesn't it seems like you would need a pretty large dataset to make this worth it, right? I mean for any kind of a change event you still need to support a standard REST API, as this really only replaces the GET operation. Am I mis…

GraphQL doesn't prescribe a particular approach to mutations; it allows the server developer to specify what mutations are available. For example, at Facebook we have a storyCreate mutation, and a friendRequestAdd mutation. Mutations are just top level fields, but with side effects; because they are fields, the client sends up a selection set with the mutation. This allows the client to receive whatever data it needs…

Awesome, thanks for the explanation. My team is rolling out an REST API currently and I've always wanted a Linq/SQL type of interface to REST API's. I could definitely see GraphQL evolving in that kind of direction. Some amazingly cool open source tech coming out of Facebook these days.

Re: GraphQL Working Draft

#27

Post by jackmoore »

binarymax wrote: post #4

Why not have the query in JSON? Now you need a new parser. EDIT: Thanks for all the replies, all of them very good points, and clearly show that JSON is not the most elegant option for a complex DSL.

I believe Netflix's Falcor, which seems very similar to Relay, uses JSON.

Re: GraphQL Working Draft

#28

Post by thechao »

I always enjoyed XPath as a lighter-weight mechanism for querying trees. It turns out that there are a set of pretty straightforward changes that can be made to XPath to have it support graphs. To wit: add a notion of a named 'traverser' (depth- vs breadth- search; pre-, in-, or post- order; how nodes are marked; etc.); then, change the notion of 'parent' to 'in' and 'child' to 'out'. XPath can then be implemented as syntactic sugar on top of this lower level "Graph Path" mechanism.

I'd always intended to convince my advisor to have the grad students do a graph-path implementation on top of boost::graph, in his generic programming course; alas, never happened. The 'masters' version of this would be to do a lazily evaluated version of graph path in C++ and Haskell to "teach them the students a lesson".

Post reply on HN