

Relay Technical Preview - cpojer
http://facebook.github.io/react/blog/2015/08/11/relay-technical-preview.html

======
AlwaysBCoding
I'm totally cool with Facebook mining my data if their open source keeps up
this pace. GraphQL + Relay are total game changers for structuring web +
mobile applications. Code bases get cleaner and more reliable. Less data gets
sent over the wire. Other cool libraries are going to be built on top of Relay
(I'm pretty excited to see what can be done now with ClojureScript components
in .cljc files).

This is so awesome. Much love to everyone at Facebook that has made this
possible. With React, React Native, Rebound, GraphQL, Relay etc... You're
saving us all from drowning in complexity when buiding web/mobile apps and I
love it. Keep fighting the good fight.

~~~
aaron-lebo
So I'm drinking the React kool aid, anyway, but this stuff has hardly been out
in the wild. People have been saying tech X saves us from complexity for
decades (OOP, noSQL, Knockout, Angular, etc...), and after a few years of use
we realize it's not actually a magic bullet. Again, I'm drinking the kool aid,
but maybe we should slow down on the hyperbole. Unless there are reasons to
believe that things really are different this time?

Also, totally not okay with how FB mines data; they don't get a pass on that.
Their OSS work is top notch, though. Now only if someone would take their own
technology and beat them with it. A little guerilla warfare.

~~~
bwy
OT: At this point, I am so confused at what "drinking the Kool-Aid" even
means. People on the Internet seem to use it for every meaning possible. I was
surprised to see that it has its own Wikipedia:
[https://en.wikipedia.org/wiki/Drinking_the_Kool-
Aid](https://en.wikipedia.org/wiki/Drinking_the_Kool-Aid).

And it seems like you mean exactly the opposite of what you've said, based on
that definition - you're _not_ drinking the React Kool-Aid, or drinking the
_anti_ -React Kool-Aid.

I'm not trying to impose grammar OCD on anyone by any means. Like I implied,
I'm probably one of the more ignorant people about these phrases. I just think
it's confusing when people say things like "could care less" and "drinking
Kool-Aid" when they actually mean the complete opposite. It's very bizarre to
me but OTOH I guess it's fascinating that English is just that flexible.

~~~
untog
I think his suggestion is that he is drinking the Kool-Aid while internally
questioning whether it is a good idea for him to be drinking the Kool-Aid.
Which, I agree, is sort of a contradiction, but a parseable one.

~~~
bwy
This makes more sense. He's basically saying, "I love this, but let's not get
too carried away." I now see where that comment's coming from!

Thanks. Nit-picking again, but drinking the Kool-Aid does mean "unquestioning,
... without criticism" implying that those who are drinking wouldn't have such
reservations. That's what I was confused about. Oh well. Language is evolving,
what else is new.

~~~
untog
It might not have been the original meaning but when you think of a cult
member drinking the Kool Aid (that will kill them) they might be a true
believer with no doubt in their mind, but they could also be someone who isn't
sure but is being led by peer pressure ao on.

------
stevebmark
I'm really excited about this! While working on an "isomorphic" app, data
fetching gets incredibly complicated. There are many edge cases. For example,
when rendering on the server, you have to block all renders until all data
fetching is complete. But on the client, you can show the view with a
"loading" indicator, as in _not_ block. But you only need to fetch data for
that route on the client if it _hasn 't_ been fetched on the server...the
rabbit hole is full of wheels you don't want to reinvent.

I'm hoping Relay solves the data fetch problem in a way that makes isomorphic
applications much cleaner.

~~~
sergiotapia
Meteor already does this. In your template (Blaze) you can wait for your
subscriptions to be ready and in the meantime render a loading icon or
something else. Check it out!

~~~
alanning
In this case, I think the more accurate example would be Meteor + React [1].
You can still show the "wait for data to be ready" state as you described.
(For those interested, follow the linked tutorial.)

The Kadira team have even gotten Server-Side Rendering working with React
[2][3] while no-one has yet for Blaze because the Blaze templates aren't
currently available on the server due to how the bundler works. I'm sure MDG
will make them available soon and then we'll be able to have SSR with both
React and Blaze.

1\. [http://react-in-meteor.readthedocs.org/en/latest/](http://react-in-
meteor.readthedocs.org/en/latest/)

2\. [https://github.com/kadirahq/flow-
router/tree/ssr](https://github.com/kadirahq/flow-router/tree/ssr)

3\. [https://kadira.io/blog/meteor/meteor-ssr-support-using-
flow-...](https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-router-
and-react)

------
picardo
This is very exciting. Facebook's commitment to open source never ceases to
impress me. They could keep this technology to themselves and have light years
or we'd only read it in academic papers, like Google has done with its core
technologies, and someone else would have to reverse engineer them. But
Facebook gives the entire code base. No other large company I know of has such
a strong commitment to open source.

~~~
marcell
> we'd only read it in academic papers, like Google has done with its core
> technologies

Nit: Google has been pretty generous in supporting developers outside the
company. Eg., see Golang, Kubernetes, JS closure library, protofubf, bazel,
and many more at github.com/google.

~~~
thrownaway2424
Not to mention being a top contributor to the Linux kernel, clang/llvm, mysql,
doing almost everyone's security research for them (including, notoriously,
finding most of the issues that get released in Apple security patches), etc.
Facebook sure does a better job of evangelizing their own open source stuff,
but I'm not sure that means they're actually contributing more. Even some of
Facebook's "contributions" are ripped off from Google, like buck.

~~~
LegNeato
Buck was not "ripped off" from Google any more than Hadoop was "ripped off"
from Google.

~~~
thrownaway2424
Buck is a nearly verbatim clone of the build system used inside Google, except
that the word "blaze" has been replaced by the word "buck", and it was written
by xooglers at facebook.

------
TheAceOfHearts
The release commit is really the best:
[https://www.dropbox.com/s/9gx377scddhxo95/Screenshot%202015-...](https://www.dropbox.com/s/9gx377scddhxo95/Screenshot%202015-08-11%2012.35.52.png?dl=0)

All I can say now is: ༼ つ ◕◡◕ ༽つ Got RELAY

~~~
falcor84
Just putting a live link to that commit here:
[https://github.com/facebook/relay/tree/2a86be3e71cdc6511fa99...](https://github.com/facebook/relay/tree/2a86be3e71cdc6511fa994e3de539f72070da1b4)

------
_mikz
Have you seen the actual code of the mutations?

[https://github.com/facebook/relay/blob/master/examples/todo/...](https://github.com/facebook/relay/blob/master/examples/todo/js/mutations/ChangeTodoStatusMutation.js)

It is ... massive!

~~~
yazaddaruvala
One thing I think is a poor design choice on the part of the implementer of
this example:

Note: Not a design choice of Relay

Is that each Mutation file is redundant. Each Mutation file corresponds one -
one with a component file. I think it does a big disservice to React itself
(specifically JSX), which advocates for collocating View and Template because
of cohesion.

Maybe its subjective.. and I can surely see the reasons for separating them,
but I hope yungsters is reading this and collocates the mutations.

~~~
underwater
Mutations are global, not view specific. They can be triggered by multiple
views, and are smart enough to only refetch the data that is currently being
shown.

For Facebook we can write a single "like" mutation and share it between
comments, posts, photos, etc.

------
pathsjs
Can anyone explain what this is all about? I followed the tutorial, but still
cannot understand what are the ideas behind Relay/GraphQL. There must be some
principles why the application is structured that way, but without seeing
them, it looks like layers of indirection for the sake of complication.

When React came out, the core ideas were crystalline, and I was able to see
the advantages in 5 minutes and to actually start doing something in 15. I
would be happy to share the excitement for Relay... anyone care to explain?
:-)

~~~
alexobenauer
Nothing explains the motivations for Relay/GraphQL better than their
introduction of it earlier this year, I'd recommend watching the video:
[http://facebook.github.io/react/blog/2015/02/20/introducing-...](http://facebook.github.io/react/blog/2015/02/20/introducing-
relay-and-graphql.html)

~~~
pathsjs
Is there anything in text format? I really cannot follow the whole video right
now. I tried to follow the slides, but they do not make much sense alone.

Here are some examples of things I do not understand.

The article below the video states that "By co-locating the queries with the
view code, the developer can reason about what a component is doing by looking
at it in isolation" but nowhere in the tutorial treasure hunt application I
see this in action. There is a single React component called App, and I fail
to see where it declares its data dependencies.

Moreover, according to the article, "Each component specifies its own data
dependencies declaratively", but it seems that a core concept is that of
mutation, which does not sound very declarative (although I am not sure I
understand what that is exactly). The code for the mutation seems to access
the this.props (which I assume live on the component). This looks like a
cyclic dependency between components and mutations. The mutation also access a
query over something called CheckHidingSpotForTreasurePayload which seems to
be defined only in schema.json, although - if I understand correctly - that
json is auto-generated.

All of this leaves me confused, which is why I was asking for a more
conceptual explation. In other words: given the aims expressed in the article
you linked (declarative data dependencies and so on), what is the reasoning
that lead to the actual design of Relay?

------
timtadh
I wish facebook had not used "GraphQL" as their name for their SOAP/REST/RPC
replacement. When I hear GraphQL I think of a query language for graphs. Like
in (for instance)
[http://dl.acm.org/citation.cfm?id=1368898](http://dl.acm.org/citation.cfm?id=1368898)
. There has been a lot of cool research over the years on query languages for
graphs. Facebook's "GraphQL" is totally nerfing Google's ability to find it.

------
lewisl9029
Any idea why they decided to use string-based queries for GraphQL?

I feel something that can be composed programmatically without having to deal
with string concatenation like Falcor's queries or the Datomic Pull syntax
proposed in Om Next [1] could be more flexible and robust. I may be missing
something.

[1]
[https://www.youtube.com/watch?v=ByNs9TG30E8](https://www.youtube.com/watch?v=ByNs9TG30E8)

~~~
tracker1
You can always use JS/ES6 string templates (using Babel or Traceur).

------
jmcatani
The major advantage of Relay/GraphQL seems to be if you have one monolithic
data model for your entire codebase. You are in effect, binding your views
directly to your backend. This is great if you are a company like Facebook
with a single graph holding all data.

Sadly working as a consultant, using Relay as prescribed offers little use for
me as I port from client to client with widely different data models. I am
interested in maybe using Relay in parent React components to keep logical
separation between my models and views.

~~~
dbb01
This is actually incorrect. The Relay/GraphQL folks explicitly call out the
concept of directly exposing your persistence structure via GraphQL as
detrimental. Instead, you simply describe what your business models are with
GraphQL (regardless of how they're stored), just as you would with a REST api.
GraphQL acts as an abstraction layer on top of your persistence. The key
difference with GraphQL vs a REST API is that you don't have to commit
specific endpoints that return specific models, the clients can simply pick
and choose (within the confines of what your GraphQL schema allows).

------
knite
I've skimmed the Relay and GraphQL repos, but I can't for the life of me
figure out which database backends are supported. Can I put this in front of
Postgres? Redis? How do I stand this up in front of an existing DB?

~~~
iamflimflam1
From what I understand you build that bit yourself

[https://www.reindex.io/blog/building-a-graphql-server-
with-n...](https://www.reindex.io/blog/building-a-graphql-server-with-node-js-
and-sql/)

------
chadly
How does this compare with Flux? Is it intended to be used with Flux or
instead of Flux?

~~~
underwater
It should be used instead of Flux.

The one caveat is that Relay's store is a representation of the data you've
defined in GraphQL. So you can't use it to store data that shouldn't exist on
the server. That's something we'd like to fix soon.

~~~
quicksnap
Is it not advisable to use Relay alongside Flux? I would think they could
compliment each other nicely.

~~~
underwater
You can, and we do exactly that for some apps at Facebook. Ideally Relay could
completely replace Flux. This is something we hope to build soon.

------
polskibus
Can someone explain to me how are they using all JS (node incl server-side
rendering) stack in a company that is known for using PHP on the backend ?

Do they have a specific PHP-to-Node bridge on the server side? If they write
isomorphic code, either they are writing apps completely separate from PHP or
they have some kind of integration (Node-in-PHP?) running?

I would be grateful for hints, I'm looking into working more with FB tech but
I can't do Node on the server right now. Knowing how their architecture looks
like with PHP/Hack on the backend would really help.

~~~
petrbela
Their GraphQL server is written in PHP. They've made the reference
implementation (graphql-js) in JS + the server in Express but they're not
using that in production.

For server side rendering of the React app, they use
[https://github.com/reactjs/react-php-v8js](https://github.com/reactjs/react-
php-v8js) (well they probably use a slightly customized version but this is
what they open sourced).

~~~
cpojer
We are not using php-v8js for server rendering at FB.

~~~
petrbela
I stand corrected. :)

------
foxhedgehog
Exciting. So does this do away with implementations of Flux (like the
excellent Redux), or is there room for them to work in concert?

------
TeeWEE
The idea of Relay is cool. And GraphQL is indeed a nice thing for mobile
engineers and product developers. I think its a novel way to query data.

Note: i'm mainly covering GraphQL

What i'm missing is implementations. For graphql you want a Java/python
implementaion ready that can be hooked into your storage engine.

For iOS / Android you need some code generation tools that can generate your
clientside business objects from the graphql schemas.

When i think about it, GraphQL combines the best of the SOAP/XML era (schemas,
type safetype, client generation) with the new REST/JSON world (low footprint,
simple structures).

However, it is still very difficult to adopt it. And most of the times, in a
startup environment, you are faster implementing a rest api. And building your
app on top of that. A schema (something like swagger, jsonschema) might help
with client side code generation.

------
leothekim
This is the best commit message:

༼ つ ◕_◕ ༽つ Give RELAY

[https://github.com/facebook/relay/commit/2a86be3e71cdc6511fa...](https://github.com/facebook/relay/commit/2a86be3e71cdc6511fa994e3de539f72070da1b4)

------
zkhalique
Wow, looks like what we've been doing for the last 4 years is very similar to
the design of Facebook's tools they've been open sourcing. That is some
serious validation for our architecture!

(For anyone who's interested here was our design:
[http://platform.qbix.com/guide/tools](http://platform.qbix.com/guide/tools),
[http://platform.qbix.com/guide/messages](http://platform.qbix.com/guide/messages))

~~~
hokkos
It doesn't look like relay at all, could you clarify what design is the same ?

~~~
zkhalique
This stuff:

 _Relay coalesces queries into batches for efficiency, manages error-prone
asynchronous logic, caches data for performance, and automatically updates
views as data changes.

Relay is also component-oriented, extending the notion of a React component to
include a description of what data is necessary to render it. This colocation
allows developers to reason locally about their application and eliminates
bugs such under- or over-fetching data._

We do the same thing (we call it the _getter_ and _batcher_ pattern). See
[http://platform.qbix.com/guide/patterns](http://platform.qbix.com/guide/patterns)

Briefly, the way it works is that you request a certain object, and don't have
to worry about batching, throttling, caching, etc. You can also say "please
call this function when all the following objects are fetched".

Our platform is also heavily based around _events_ for which _handlers_ are
automatically unregistered when _pages_ and _tools_ are removed. So it's same
as with facebook.

Plus we already support most of the following:

 _Offline support. This will allow applications to fulfill queries and enqueue
updates without connectivity.

Real-time updates. In collaboration with the GraphQL community, we're working
to define a specification for subscriptions and provide support for them in
Relay.

A generic Relay. Just as the power of React was never about the virtual DOM,
Relay is much more than a GraphQL client. We're working to extend Relay to
provide a unified interface for interacting not only with server data, but
also in-memory and native device data (and, even better, a mix of all three).

Finally, it's all too easy as developers to focus on those people with the
newest devices and fastest internet connections. We're working to make it
easier to build applications that are robust in the face of slow or
intermittent connectivity._

See
[http://platform.qbix.com/guide/messages](http://platform.qbix.com/guide/messages)

------
nwmcsween
So graphql is basically a query language and optimizer? Why not have a
relational algebra library, query (sql, whatever) generator and optimizer as
separate things?

------
platz
Seems like it has some similarites to OData.

BreezeJS is a stand-alone data library for SPAs which takes care of managing
the lifecycle of data objects; querying, fetching, caching is all taken care
of. Queries use OData by default

------
darkmarmot
Aspects of React, Relay and Flux make me feel like my company's js framework
could end up like Leibniz once we release it this fall...

~~~
iLoch
A word of caution: you're probably right. React, Angular, Backbone cover most
use cases and are proven in production, well known, and well understood.
Unless you're a big company with hard problems, why should anyone pay
attention? Not to rain on your parade, I've had the inclination to build my
own libraries in the past as well but I always remember why it's not a good
plan.

Any new framework these days has to bring a ton of innovation and performance
to the table - is your framework faster and easier to use than React? Does it
fulfill use cases that React cannot? How many more use cases can React fit
than yours? Hint: There's React Canvas, React Native, React WinJS, and you can
run it on your server. There's also approximately a billion modules for these
libraries combined.

There are plenty of examples of projects that are DOA. If you want yours to be
successful you'll REALLY have to sell it. Not that I'm rooting against you! :)
If your library is more innovative and more powerful, more power to you!
There's nothing wrong with progress. I'm just skeptical because the
aforementioned libraries work for nearly 100% of companies.

------
fiatjaf
More undebuggable magic.

~~~
fiatjaf
I had 12 upvotes here, and then returned to 1.

------
gamekathu
another _awesome_ gift from facebook, thanks a lot devs! but i am still
eagerly waiting for React native for Android.. any updates on its development?

------
aikah
> While working on an "isomorphic" app

now you should say "universal", "isomorphic" was a poor choice of words at
first place and led to a lot of misunderstanding(and bad blood between js
developers and mathematicians)

[http://www.infoq.com/news/2015/08/netflix-universal-
javascri...](http://www.infoq.com/news/2015/08/netflix-universal-javascript)

> As applied to JavaScript, Charlie Robbins presented the idea in 2011. He
> called it "Isomorphic JavaScript" which has resulted in years of debate over
> the poor name. In recent months, the term Universal JavaScript has gained
> acceptance.

~~~
aaron-lebo
Words take on new, unintended, and incorrect meanings all the time. It's how
language works.

When someone says "isomorphic JS" I know exactly what they are talking about.
I understand why some people might push back against it, but there's nothing
wrong with the term.

~~~
aikah
> Words take on new, unintended, and incorrect meanings all the time. It's how
> language works.

No, that's how marketing works. We are developers not salesmen. and as
computer scientists respecting other science branches is a duty. Using the
expression "isomorphic" in that context is just confusing. And it makes
developers sound like they haven't a fn clue what they are talking about.

~~~
mindcrime
_We are developers not salesmen_

Speak for yourself. Some of us are both.

 _and as computer scientists respecting other science branches is a duty.
Using the expression "isomorphic" in that context is just confusing._

That's a fair point, but "context" is the key word. Using "isomorphic"
incorrectly _in a mathematical context_ would be one thing. But borrowing the
word to use in a largely unrelated context seems fine to me. And it isn't like
this is the first time a word has been borrowed and used to mean something
"similar or related, but not quite the same". I'm pretty sure this has even
happened inside other scientific disciplines, although I'll grant you that I
don't have an example at my fingertips.

~~~
reinhardt
I would be more sympathetic if they had "borrowed" (more like appropriated) a
term from, say, biology or french literature, but mathematics is not exactly a
"largely unrelated context" from programming, even if it's JS that we're
talking about. What's next, abusing "binomial" to mean "binary"?

