[jimmcslim]

In some ways GraphQL reminds me of Microsoft's OData.

It seems entity-centric though. What would a GraphQL 'mutation' look like that kicked off some process requiring the identity of say 3/4 entities plus some of its own input?

[skrebbel]

OData was nice on paper and very impractical in reality. I strongly fear that this is just Facebook reinventing it, making the same mistakes, but taking thousands of developers along with them because it's by Facebook and not Microsoft.

The big issue with OData is that it is highly flexible, and as such rather difficult to make cover all cases and keep it performant.

But maybe the real problem was simply that no good OData servers existed, barring the one from MS that tied directly with their ORM and thus your data model.

I really suspect that the flexibility that GraphQL gives immediately translates to complexity on the server side.

It feels like this is ORMs all over, just now between the frontend and the backend instead of the backend and the database. Give it a couple of years and we'll see the REST-version of the "just use plain SQL!" blog posts: "just hand-craft highly specific REST endpoints for exactly what your frontend needs!"

[schrockn]

Hi I'm Nick Schrock one of the GraphQL developers at Facebook.

While GraphQL certainly shares some attributes with OData, we believe it is substantially different enough from Data that we aren't simply repeating the same mistakes.

There are a number of differences, but two in particular are striking.

1) Is that the GraphQL language is built with product developers in mind. This is a subjective/qualitative judgement, but we believe that it's just a much more elegant language, and that it is a more powerful platform for tool-building. We hope to prove this out in the coming months as both we and the community build tooling atop the language and the introspection system. 2) GraphQL is more constrained. A OData service has to support a huge number of operations that make it more of a generic querying service, rather than a highly structured way to expose application logic. We agree with you that often cover too much and without adequate performance guarantees.

In terms of complexity on the server side, I think this is a really legitimate question. Our answer is that although there is complexity, it is generally incurred on a much smaller set of core and tool developers. The average product developer who will just need to expose a capability via a GraphQL type and then consume it on the client will not find the system overly complex.

[skrebbel]

A bit late so you might not read this, but I really like your response and it's going to make me take a deeper look at GraphQL. Thanks for the writeup!

[onion2k]

I strongly fear that this is just Facebook reinventing it, making the same mistakes, but taking thousands of developers along with them because it's by Facebook and not Microsoft.

This sounds like you think more developers pay attention to what Facebook do than Microsoft. If that's the case then you are a long way off. A really long way.

[vidarh]

Not necessarily more developers, but different developers, I suspect.

[Touche]

Interesting comparison. I didn't remember ODATA having a way to specify queries but I guess I was wrong: http://www.odata.org/getting-started/basic-tutorial/#select