GraphQL Working Draft (opens in new tab)

New link: https://www.youtube.com/watch?v=WQLzZf34FJ8

That link says "This video is private".

There are certain things that are a bit more elegant if you can have a custom query language. One example:

        query UseFragment {
          luke: human(id: "1000") {
            ...HumanFragment
          }
          leia: human(id: "1003") {
            ...HumanFragment
          }
        }
        fragment HumanFragment on Human {
          name
          homePlanet
        }

You could definitely have some JSON to represent this but it might turn out to be more trouble than it's worth...

It's sad that you capitulated. I agree with your original point more. Is this thing really flexible, composable, and implementable? How long do we have to wait for people to provide solid implementations on top of all the popular programming language and database backends? Feels like SQL all over again. Someone will be writing layers on top of this in javascript in the frontend and ruby/python/javascript/etc. in the backend. Then we are in another ORM hell. (Perhaps I am being too pessimistic here, it could very well be great, but I have some serious reservations...)

the query contains by far more logic than should be put into json

you could map it to json - but technically you could map everything to json - doesnt mean you decrease complexity

the parser is the lowest problem of parsing and optimizing those queries i'd assume

Readability I guess. The new syntax looks pretty good to me. A little heavy on the (( and )) but very obvious as to what is being asked.

I'm guessing you might want some 'small' parts of logic, like the unary operation. Guessing!

MongoDB did JSON queries. After having useed it I don't think it's a good idea at all.

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

> cult of REST

Is this a thing?

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.

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.

Just fyi, the doc mentions mutations here: http://facebook.github.io/graphql/#sec-Language.Operations

With a talk from earlier this year that describes an implementation: https://facebook.github.io/react/blog/2015/02/20/introducing...

They are orthogonal; graph ql is for fetching data and is supposed to be an alternative to writing a new backend endpoint for every ui-thing that needs some slice of data, flux is a pattern for organizing data flow in the UI.

I think you mean falling back to "FQL," the old SQL-like syntax, since Flux is more of a client architecture thing (paired with GraphQL).

FQL has some holdouts in legacy code, but the vast majority of the iOS app is using GraphQL. There are a bunch of tools built around using it, and it's the "right way" these days. Maybe a year or more ago ago, the notifications tab was using FQL. It makes sense to convert things since the risk in switching is outweighed by a reduction in server CPU, network bytes transferred, and ability of tools to understand the code. When we built Paper, we did notifications on GraphQL because there wasn't the risk of breaking something.

You can almost certainly handle all of your 'data needs' with GraphQL... :D

Perhaps that code is a bit misleading. The schema itself is defined and provided by the server. The idea being that a server would build up it's type definitions, and then call into graphql's executor providing both the schema the server defined (in code) as well as the query the client provided (as a network request)

It's passed to that function in the reference implementation, but a server would probably create a helper function that runs a query for a particular schema. For example, you can just pass a query to Facebook's GraphQL endpoint (without specifying a schema), and it will run the query on the Facebook schema.

There's a JS server provided: https://github.com/graphql/graphql-js.

Unlike with RESTful APIs, a server basically only needs a single endpoint that parses and responds to GraphQL commands. This isn't as far off as you suppose to be the case.

They are attempting to solve similar problems: describing data needs on a client in a way that integrates well with how the data is used, and fulfilling those requirements efficiently.

Falcor uses some different primitives to accomplish the task, focusing on connecting together Observables, whereas GraphQL queries are written in a small query language.

Falcor is a super interesting project and we've gotten to swap notes a couple times.

That's because it is 4!

https://www.facebook.com/4

As a ruby programmer, my gut reaction was that this had something to do with bugs caused by the object id of `nil` being 4. But of course that's not the case :)

Who is 1,2,3 ?

It is :)

Joe Savona says August.