It really pleases me to finally see a big credible player tackling the REST orthodoxy. They state very well why REST APIs are not working well for mobile.<p>Notably:
"Fetching complicated object graphs require multiple round trips between the client and server to render single views. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable."<p>Now, I'm wondering how they manage to make the computation of the responses on the server side no too expensive. It seems clear that there is a risk in such a system to define queries that pull way too more data at once. Also, the question of pagination comes to mind. How can you handle that efficiently?
As an ex-Facebook employee, I can't wait for this to be released to the public. It is hard for me to overstate how much this infrastructure makes building products a joy, not to mention the tremendous developer and server efficiency that can be attained. I miss having the GraphQL stack so much when working on my own stuff.<p>The client application should drive the decisions about what data to fetch. After all it's the client that knows what it is actually going to be doing with the data, not the server. Current approaches like having a "fields" option on a REST endpoint are at best a hacky approximation to this.
The reasons they list in favour of GraphQL vs REST and Ad HOC APIs are really convincing. Being a developer for an API that powers multiple mobile applications and a website this looks really interesting and would solve a lot of problems we have right now. Unfortunately I know it would probably take too much time to re-implement all our backend and clients to even think about using this in a near future.
People often talk in terms of there being only two layers of a webstack: The client/webapp layer and the server layer. I think what Netflix did (explained <a href="http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html" rel="nofollow">http://techblog.netflix.com/2012/07/embracing-differences-in...</a>) is really the way to go.<p>It would be nice having custom adapter endpoints for your clients and devices that in turn fans out multiple calls on the backend border (if you are using a service based backend architecture), while still having the option of going directly to the service endpoints for third party integrations and what not. Having this adapter layer based on GraphQL would be neat, assuming one could break down GraphQL queries to individual REST based endpoint calls.
What are the alternatives to using something similar to GraphQL and Relay now? I've found Transmit [0], but what are the other alternatives? Has someone tried to integrate BreezeJS [1]? Also, any news about the upcoming Falcor [2]?<p>[0] <a href="https://github.com/RickWong/react-transmit" rel="nofollow">https://github.com/RickWong/react-transmit</a><p>[1] <a href="http://www.getbreezenow.com/" rel="nofollow">http://www.getbreezenow.com/</a><p>[2] <a href="https://www.youtube.com/watch?v=WiO1f6h15c8" rel="nofollow">https://www.youtube.com/watch?v=WiO1f6h15c8</a><p>P.S. Also, GraphNoQL [3] came out quickly after the announcement, but there's been no progress ever since.<p>[3] <a href="https://github.com/lutherism/GraphNoQL" rel="nofollow">https://github.com/lutherism/GraphNoQL</a>
FYI - I enjoyed a podcast recently on GraphQL/Relay -
<a href="http://devchat.tv/js-jabber/152-jsj-graphql-and-relay-with-nick-schrock-and-joe-savona-" rel="nofollow">http://devchat.tv/js-jabber/152-jsj-graphql-and-relay-with-n...</a>
I don't see why using something like GraphQL should push REST out of the way.
I want to create and manage my resources, publish them on the web via a RESTful API - and also provide a way for the user to query those resources in a meaningful way with just one call.
That's exactly what I'm doing today - but with a proprietary language (and querystring - which is not ideal).<p>I see this as the perfect companion for REST and I hope it will be standardized.
Kudos
Excuse me for being unreasonably giddy but I've been eager as hell for this to be released for a time. I have grown to adore React and React Native and really enjoyed Flux. Facebook dev hitting on all cylinders!
If you can't use GraphQL due to some reason then there is an alternate - <a href="http://www.getbreezenow.com/breezejs" rel="nofollow">http://www.getbreezenow.com/breezejs</a>
Since there is already a mix of predicates within the query (for sub objects) they should have unified the syntax. Something like:<p>user {<p><pre><code> id: 3500401,
name,
isViewerFriend,
profilePicture {
size= 50,
uri,
width,
height
}
}
</code></pre>
As shown you could use a different indicator for filter properties that should not be included in the serialized object graph.
This looks seriously useful, but I'm having a hard time seeing how something like Relay will play ball with, say, vector clocks, or client-side undo, as it sounds fairly welded to the Component.<p>Maybe the idea is to do that all on the server? Or in the Store? Very curious to see the implementation.
This is great. Can't wait for the actual release. One question I have is how GraphQL/Relay works for writing/modifying data on the server?
1. How much more complicated does this make the server? Seems like some pretty fancy code would have to be written to turn GraphQL tot SQL.<p>2. I think the biggest issue with HTTP verbs is that there is not an flexible way for the client to control the data that comes back from server. GETs dont have a body and the other verbs are for add/mod of data. I'm assuming that they are using POST for everything.