
GraphQL Introduction - jbraithwaite
https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html
======
madewulf
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.

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?

~~~
schrockn
Re: 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.

~~~
madewulf
Thanks a lot for these insights. I'm definitely looking forward to discover
more about all this.

------
nroman
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.

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.

~~~
command_tab
I'm curious to learn how API response caching is affected by GraphQL. In a
REST setup, there's a possibility that API responses can be cached. But if the
response structure is dictated by the client, it seems like responses might
differ and not be cacheable.

~~~
nroman
In practice it wouldn't make much sense to cache whole query responses to
GraphQL queries because your hit rates would be too low due to the variability
of the queries. You end up pushing a lot of the caching to the client. That's
not really a big issue because if you're writing something like a Android or
iOS app because you already need to be caching lots of data on the client-side
to make the app responsive.

On the server you end up caching at lower levels in the stack. For example a
query for user(id: 123456) {id, name} is going to need data from a key-value
store containing user info. That access can easily be cached with something
like memcache, saving load on the database. Cache-invalidation problems are
also much easier to solve at these layers.

~~~
rapind
Worth noting there's a massive performance penalty to pay when caching at the
app level depending on your stack. On hardware where rails + memcached is
struggling to handle 500 concurrents varnish or Nginx will easily handle tens
of thousands.

------
Chris911
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.

------
frnktrn
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
[http://techblog.netflix.com/2012/07/embracing-differences-
in...](http://techblog.netflix.com/2012/07/embracing-differences-inside-
netflix.html)) 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.

------
kolev
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]?

[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
If 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
Thanks! I'm definitely gonna look into it!

------
ahains
FYI - I enjoyed a podcast recently on GraphQL/Relay - [http://devchat.tv/js-
jabber/152-jsj-graphql-and-relay-with-n...](http://devchat.tv/js-
jabber/152-jsj-graphql-and-relay-with-nick-schrock-and-joe-savona-)

~~~
schrockn
Thanks!

------
framp
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).

I see this as the perfect companion for REST and I hope it will be
standardized. Kudos

------
UUMMUU
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!

------
mandeepj
If 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
Well, 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.

------
achr2
Since 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
Yeah, 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.

------
donw
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.

Maybe the idea is to do that all on the server? Or in the Store? Very curious
to see the implementation.

------
jefftchan
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?

------
wehadfun
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.

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
It 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.

~~~
iLoch
Can you comment on whether or not you'll be releasing any implementations and
if so, what languages they'll be in?

~~~
WimLeers
+1, knowing the languages of the open sourced implementations would be very
helpful.

------
reinhardt1053
Basically an ORM with JSON request/responses, isn't it?

------
mosselman
So is Relay an alternative to Flux or how are the two related?

~~~
ChrisGaudreau
[http://facebook.github.io/react/blog/2015/02/20/introducing-...](http://facebook.github.io/react/blog/2015/02/20/introducing-
relay-and-graphql.html#how-does-it-relate-to-flux)

~~~
mosselman
I 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
Relay 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.

