6 ms·
GraphQL Introduction
- UUMMUU 11y agoExcuse 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!
- mandeepj 11y agoIf you can't use GraphQL due to some reason then there is an alternate - http://www.getbreezenow.com/breezejs http://www.getbreezenow.com/breezejs
- kolev 11y agoWell, we have to wait a few months for GraphQL to get open-sourced, but, anyway, I find BreezeJS better personally as defining GraphQL in strings is more old-school than using promises or generators.
- kolev 11y agoWhat 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]? [0] https://github.com/RickWong/react-transmit https://github.com/RickWong/react-transmit [1] http://www.getbreezenow.com/ http://www.getbreezenow.com/ [2] https://www.youtube.com/watch?v=WiO1f6h15c8 https://www.youtube.com/watch?v=WiO1f6h15c8 P.S. Also, GraphNoQL [3] came out quickly after the announcement, but there's been no progress ever since. [3] https://github.com/lutherism/GraphNoQL https://github.com/lutherism/GraphNoQL
- roskilli 11y agoIf you only care about iOS and a layer on the backend that can sit between your actual app server and the client you could consider Jetstream: https://github.com/uber/jetstream https://github.com/uber/jetstream https://github.com/uber/jetstream-ios https://github.com/uber/jetstream-ios It's a considerably different model however. More about realtime updates.
- kolev 11y agoThanks! I'm definitely gonna look into it!
- kolev 11y agoForgot to add the following: JayData [0], engen [1], and Astarisx [2]? [0] http://jaydata.org/ http://jaydata.org/ [1] https://github.com/storehouse/engen https://github.com/storehouse/engen [2] https://entrendipity.github.io/astarisx/ https://entrendipity.github.io/astarisx/
- nroman 11y agoAs 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. 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.
- slycoder 11y ago+1. Having gotten used to GraphQL I was shocked how hard it was to build something REST-ish at another org.
- steego 11y agoAs someone who's used OData for this sort of strong typed, ad-hoc interaction with the server, I'm really happy to see Facebook push this idea. Compared to OData, I really like how GraphGL's approach of making a query look like the data it's requesting.
- MasonOfWords 11y agoI don't know, there are some tradeoffs there. Their sample appears to be "nearly JSON", which doesn't seem too helpful. Being close to but noncompliant with a standard doesn't bring anything but confusion. And it isn't obvious what they're using for transport, but it seems like they aren't attempting to model programmatic resources as web resources the way that OData does. This is an okay decision if they're trying to make it transport-neutral (i.e. you can issue the same GraphQL request via Thrift or by HTTP POST), but in that direction lies the sins of SOAP. In the past I've written a client-side caching layer for OData which was capable of doing the same automatic batching and partial cache fulfillment for hierarchical queries that they describe in the article. It is a good tool for writing complex client applications against generalized data services without giving up performance, and I'm not surprised that companies in our post-browser world are starting to move in that direction. I'm a little bummed that Facebook is throwing its considerable weight behind yet another piece of NIH-ware, though. Beating up the REST strawman was a poor use of half of this article; I'd be much more interested to hear why we need GraphQL when there exists a standard like OData.
- Chris911 11y agoThe 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.
- ossreality 11y agoIt's like there's a calculated trickle of info to keep us interested as they prep it for release. Good job, it works.
- donw 11y agoThis 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. Maybe the idea is to do that all on the server? Or in the Store? Very curious to see the implementation.
- madewulf 11y agoIt 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. 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." 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?
- vosper 11y agoIt seems to me that GraphQL could be awesome when you exclusively control the back-end and the front-end, but do you think it will work as well if you're building an API that also needs to support third-party clients? Would REST still be better in that scenario? Edit: I see that they partially address this: "Many of these attributes are linked to the fact that “REST is intended for long-lived network-based applications that span multiple organizations” according to its inventor. This is not a requirement for APIs that serve a client app built within the same organization."
- schrockn 11y agoThat's a great point. We definitely have designed it for first party clients in mind. This doesn't preclude use cases in the future, but for the short term, this is a nongoal.
- schrockn 11y agoRe: the risk of overfetching, this is certainly a risk. Like any tool, it can be misused. One of the motivations of Relay is in fact this very issue. By coupling the data-fetching with the view more tightly, we can more accurately track and fix overfetching earlier in the development cycle. In terms of being not too expensive, an important attribute of the system is that the server publishes capabilities that clients selectively use. For example, we explicitly do not allow clients to send up arbitrary strings for filtering and query predicates and what not; servers have to explicitly expose those via arguments to fields. eventMembers(isViewerFriend: true) { ... } or similar formulations that are encoded in the type system. This prevents people from ordering inefficiently (e.g. large data sets without indexes). Re: pagination. This is absolutely a core pattern that we are excited to talk about as we explain the system more. Broadly we handle pagination through call arguments, e.g. friends(after: $someCursor, first: 10) { ... } There's a lot of subtlety there which I won't go into until we dive into that topic deeply.
- wehadfun 11y ago1. 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. 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.
- schrockn 11y agoIt is absolutely not that simple on the server, but we hope do to a lot of the heavy lifting for you via our open source release of code and spec in terms of lexing, parsing, and executing a query.
- mosselman 11y agoSo is Relay an alternative to Flux or how are the two related?
- ChrisGaudreau 11y agohttp://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html#how-does-it-relate-to-flux http://facebook.github.io/react/blog/2015/02/20/introducing-...
- mosselman 11y agoI read that already :) thanks. The question I have is rather whether Relay is an alternative to Flux or that the two are meant to be used in conjunction. Also, which usecases would make Flux better and which Relay (if they are not to be used together).
- leebyron 11y agoRelay is one specific implementation of the Flux pattern. Flux is a generalized pattern and there are a number of libraries out there which implement their own flavor of Flux. Relay is one of those libraries implementing the Flux pattern which focuses on describing data dependencies in the same place the data is used.
- jefftchan 11y agoThis 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?
- ahains 11y agoFYI - I enjoyed a podcast recently on GraphQL/Relay - http://devchat.tv/js-jabber/152-jsj-graphql-and-relay-with-nick-schrock-and-joe-savona- http://devchat.tv/js-jabber/152-jsj-graphql-and-relay-with-n...
- schrockn 11y agoThanks!
- framp 11y agoI 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). I see this as the perfect companion for REST and I hope it will be standardized. Kudos
- reinhardt1053 11y agoBasically an ORM with JSON request/responses, isn't it?
- frnktrn 11y agoPeople 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 http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html http://techblog.netflix.com/2012/07/embracing-differences-in...) is really the way to go. 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.
- achr2 11y agoSince there is already a mix of predicates within the query (for sub objects) they should have unified the syntax. Something like: user { id: 3500401, name, isViewerFriend, profilePicture { size= 50, uri, width, height } } As shown you could use a different indicator for filter properties that should not be included in the serialized object graph.
- mjburgess 11y agoYeah, it's odd. It's not clear why they're just not using json... json will give you an homoiconic language of arbitrary descriptive power.