[sapeien]

I don't buy into the GraphQL hype. Actually it is a rehash of older technologies like RDF & SparQL, but marketed to a newer generation who didn't know that old things exist. I'd wager that the 20-something "engineers" who designed it didn't give a shit about prior art either.

I'm sure that Facebook employees think it solves a lot of problems for them. But I'm not convinced that a single vendor technology is going to be viable on the web. Web standards come about through standardization processes, with multiple stakeholders reviewing and revising drafts. Facebook one day puts up the GraphQL spec out of nowhere and defines the "standard" by themselves, based on their own implementation.

A little history: Facebook tried to subvert HTML with FBML, a proprietary markup language designed for use within the Facebook ecosystem. Long story short, it didn't work out. The various SDKs and APIs by Facebook have been notoriously unstable.

People tend to excel at short-term thinking, kudos to Facebook for that, and lack the foresight for long-term thinking, except for a few visionaries. The architecture of the web has lasted a few decades already, it will outlast a single vendor specification.

[geoffschmidt]

The GraphQL ecosystem has grown amazingly quickly over the last year. It's definitely not a single-vendor technology at this point. Check out this list of GraphQL libraries, tools, and implementations: https://github.com/chentsulin/awesome-graphql

The majority of people who are using GraphQL are using an implementation from someone other than Facebook (on either the client or the server, or in many cases both).

(And for what it's worth, I did see a "Why not RDF" slide in one of Lee Byron's decks, and those of us at Meteor who are working on GraphQL are definitely aware of the RDF/SparQL roots. I think what's driving GraphQL's growth is, first, it addresses a very timely problem - fetching all of the data for a screen in a mobile app in a single round trip without coupling your backend to your UI - and second, the focus on tooling and developer experience which has been a weakness for SparQL.)

[sapeien]

I didn't say that Facebook's reference implementation is the only one (it is in fact the most popular based on downloads), everyone else is performing free labor for Facebook. The point is that they can make any change they want to the spec for themselves and imposing their will, bypassing standards processes because there are none.

>fetching all of the data for a screen in a mobile app in a single round trip without coupling your backend to your UI - and second, the focus on tooling and developer experience

There is no reason why one can't do this with existing web technologies as an additional feature. There was no reason to ignore what already exists and works for the web at large.

I think you should disclose that you are founder of Meteor and have a vested interest in GraphQL. So when is the Facebook acquisition?

[ruslan_talpa]

While I also have a vested interest in GraphQL (competing in the same space as Scaphold) I agree partially with what you stated above but it's not all that bad as you seem to imply.

Yes, FB does have the power (now) to change the spec over night but so far it was mostly stable and whatever changes were added were only for the better. No new technology comes to life as a standard, it needs someone inventing it, maintaining it, promoting it up to the point where people can get behind it and form a group and make it a standard. Let's give FB a chance, so far it has done an excellent job with the GraphQL standard. On the other hand, graphql-js and Relay are not that stable yet and their interfaces are changing very fast and probably for people that use them it's a bit frustrating but it's only been a year and i bet they will get to a stable interface in 2017 enough for people to be able to really depend on them.

>There was no reason to ignore what already exists and works for the web at large.

GraphQL came to life (and a lot of people adopted it practically over night) precisely because the things that "already existed" did not work really well (REST for SPA/Mobile). When a lot of your business logic (whatever that means :)) moves to the frontend (browser/mobile), the backend API tend to become very complex in order to support the frontend and REST can not express very well that complexity. Whenever people "sell/promote" GraphQL, they bring up 2 main benefits, fetching the data you need in a single request and integrating multiple backends/microservices. If you look at GraphQL only form this perspective i would agree with you that it brings nothing radically new to the table. You can have a REST api flexible enough to be able to get only the data you need in one request (see http://postgrest.com) and you can integrate multiple microservices behind it, we've also seen in the past "typed" schemas (WSDL and things like that).

Imo what makes GraphQL so nice is the the simplicity (Rich Hickey's definition), how you immediately get what a query does, how it relates to JSON and the shape of the response you get back. Making something "simple" is very hard work and i think FB nailed it.