I wrote the gist; happy to answer questions (although out and on my phone right now so I won't be super fast).

A common problem in a service oriented architecture is needed to minimize the amount of round trips to a particular service.

Example: To render a UI view, I need to fetch a list of friends, a list of posts, and a list of notifications. All 3 of these data types (friends, posts, notifications) have users associated with them. Instead of fetching users for the 3 data types 3 separate times, I need to flatten that into a single call. I end up with something like this:

  var [posts, friends, notifs] = yield [
    getPosts(),
    getFriends(),
    getNotifs()
  ]; // executes in parallel

  var userIDs = new Set();
  userIDs.addAll(posts.map(p => p.userID));
  userIDs.addAll(friends.map(f => f.userID));
  userIDs.addAll(notifs.map(n => n.userID));

  var users = yield getUsers(userIDs.toArray());

  return {posts, friends, notifs, users};

You can see where this gets cumbersome. I have to compose one of these for every kind UI view at the root level. On the one hand it's very explicit and the flow of data is very clear, but it also means relationships between data are dupicated in more than one place (often many places).

Could GraphQL help with that scenario?

(I've used GraphQL at Facebook, but I don't work on it.)

If I understand your post correctly, I think it could. GraphQL prefers to expose full objects, rather than IDs, which lets you query for data inside objects at the same time. So for your example above, you would only need one GraphQL query:

  viewer() {
    posts {
      node {
        author { id, name, favorite_color },
        // any other post data you want
      }
    },
    friends {
      node {
        id,
        name,
        favorite_color,
      }
    },
    notifications {
      node {
        source { id, name, favorite_color },
        // any other notification fields you want
      }
    },
  }

The "id, name, favorite_color" is just a sample set of fields, you could replace it with whichever your components needed. Relay also has functionality to avoid duplicating the set of fields, which is especially useful when you want to add or remove a field from what a reusable component needs.

What language is that?

That's ES6 JavaScript (running on Node 0.11.15). We've already migrated most of our production code to this and we're loving it!

If you like that kind of control flow, check out the library we wrote to do it: https://github.com/storehouse/engen

Why not use let instead of var?

Only habit. We're so used to var. But yea, need to transition to let for most things.

I think migrating to const makes more sense. In practice only a few things require to be mutated.

Didn't realize const was in. Will definitely be using it.

I believe that's Javascript (ES6).

Great work! Relay is really exciting.

My concern is regarding the server-side implementation of the GraphQL endpoint. My understanding is that GraphQL endpoints couple tightly to a graph-oriented backend. Facebook already has TAO so it's a no-brainer, but how feasible do you think a normal SQL-based backend can adapt to efficiently process arbitrary GraphQL queries? Or would it be easier to switch to a graph-oriented database (e.g. neo4j) instead? The former option seems to be quite an engineering endeavor, while the latter is just too risky right now.

Not a Facebooker so I haven't worked with GraphQL per say (sad face), but a quick-and-dirty way to do this type of deep data fetching on an SQL database is to fetch one layer at a time: do a breadth-first search on the parsed GraphQL, and at the end of each layer you should have enough data in API-server memory to know the IDs of everything in the subsequent layer. Rails has largely switched to doing this rather than deep joins. Given that the depth is based on how many layers deep your GraphQL is, rather than the number of records, you avoid the N+1 problem without needing to switch to a graph database, and there's a relatively constant number of DB hops required. The main caveat I see is that cursor-based pagination is hard to emulate in SQL without persistent database connections... not sure if there's a scalable way to do this while keeping the GraphQL endpoint stateless.

Having experimented with neo4j a year ago, I would concur that it hasn't been battle-tested for use as a high-availability database for web apps; it was used much more for offline analytics AFAIK. Thingdom did some REALLY cool things using neo4j from JS, and their ideas for modeling news feeds were really mindblowing, but I'm hesitant to put anything mission-critical on it just yet from both a technical-debt perspective and a speed/scalability perspective.

GraphQL itself doesn't make any assumptions about the storage engine being graph-oriented or otherwise. It's true that the grammar makes it easy to express graph-like relationships (eg. using the notion of one-to-many connections), and from the perspective of the application it can request an arbitrarily complex hierarchy of nested objects, but how and where the underlying data gets fetched is implementation specific and I can imagine adapting GraphQL to any number of different data source types.

Why not just let components subscribe to specific events?

In our framework, it's mostly event based, so if some data changes, events are fired and then things happen based on subscriptions. Just wondering what advantages are offered here over that setup.

Because then it wouldn't be React. React tries to solve the conceptual spaghetti created by heavily evented systems, by putting everything into one stream of notifications so that you can immediately know where things are being changed and by what. It prefers synchronous over asynchronous for this reason also.

Sorry, what? Are you saying basically that event subscriptions are all declared in some declarative language, making them all easy to find "in one place"?

Could you give an example of the type of bug you're referring to here?

> This means that only the fields of an object that a component explicitly asks for will be accessible to that component, even if other fields are known and cached in the store (because another component requested them). We call this masking, and it makes it impossible for implicit data dependency bugs to exist latently in the system.

Component requests n fields of data, actually uses n+1 fields and the only reason the field is populated is because another component has requested the data, remove that component and boom unrelated component breaks. With GraphQL you have to specify exactly what fields you want and you can't accidentally get access to more than requested.

What tool do you use in sever side to parse graphql?

We have our own parser at Facebook. Our reference implementation will include a parser, and a we'll be releasing a spec as well so it should be possible to build alternative implementations as well, should you wish.

Is there a connection between Relay and Haxl?

no.

Code example?

https://www.youtube.com/watch?v=9sc8Pyc51uU - there are some examples in the talk from React JS Conf.

We haven't yet finalized what API we will provide when we open source Relay. You'll certainly get one object, called Relay, however ;)

Application code will look like regular React components. The only difference is you declare what data you want in a GraphQL fragment.

Here's a photo from the presentation that shows an example: https://twitter.com/devonbl/status/560532680513556481.

Much of this FAQ reminds me of a little-known library called Breeze.

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, but implements a specific subset of the query language that can rendered down and used against REST apis. Breeze also provides server libraries for different stacks to easily integrate and get up and running.

Granted the usecase of embedding declarative queries as part of a component which gets composed along with other components+queries is unique to React, but I speculate it wouldn't be too difficult to implement within Breeze.

All that said, it will be nice to see another rich-data management library to compare and contrast. The days of painstakingly writing business objects in 34 places will end.

Would it be accurate to say that Relay's approach works best for component-based apps (not React components, "component" in the more general sense) - that is, the app is made up of a bunch of mostly separate components that encapsulate their own state, like {Feed, Ads, Groups, Messaging, Photos, Events, Minifeed}, which don't really share much state and don't require central coordination?

Not really. It's true that those kinds of "components" will usually live on their own routes, but there's nothing intrinsic to the framework that favors that particular kind of app structure.

I'd like to phrase dustingetz' question slightly differently: if you're building an app that does not have multiple relatively independent parts as dustin describes, does Relay still have a major advantage over what's currently common? (i.e. if one page is only ever one "thing", how is it better than just calling the right APIs from the router be done with it?)

"Simplified server implementation: Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources."

GraphQL sounds tremendously exciting.

This looks incredible.

Especially excited at the idea of a single store. I've always had a little bit of a beef with Flux when it came to interdependencies within stores.

I feel like one of the problems with react that is currently not well solved is the integration of a client and server side router for a truly isomorphic application. There have been quite a few implementations that rely on a single om-like state that they serialize and deserialize to the client. Relay feels like it would fit extremely well into this paradigm.

Check out http://entrendipity.github.io/astarisx/ . It uses a Single Source of Truth to accomplish what you're after.

This looks very similar to a library I've been working on (live demo here for webkit browsers: http://city41.github.io/bookends/demo.html), and it was inspired by a similar framework that is used at my former employer.

Also, this is as interesting as React Native. And React Native is pretty interesting.

This is the biggest thing for JSON payload control since...JSON APIs became a thing?

What's "JSON payload control" exactly?

Confidence in returning the minimum to render a view. By default, without having to worry about over / under fetching data. Not having to worry about cleaning up endpoints when the needs of the consumer changes. A client that requests exactly what it needs, rather than hitting an endpoint with 'something', is extremely efficient.

Great answer; thanks for the clarification!

Here's the video introducing it at React.js conf: https://www.youtube.com/watch?v=9sc8Pyc51uU

If you're interested in building GraphQL with Node+Mongo, checkout this github project: https://github.com/lutherism/GraphNoQL

Wow! That was fast!

I am confused: why is data made available as props and not as state?

This https://github.com/uberVU/react-guide/blob/master/props-vs-s... is a good explanation of the difference. But in short, it essentially comes down to who can manipulate the data. If the component will manipulate it, then it is state. On the other hand, if a difference source is going to be manipulating it, then it should be a prop. In this case, the client side of relay will be changing the data according to instruction from the server (e.g. a new message arrived). Therefore, the state is being passed as a prop.

Does Facebook list browser requirements for all of this anywhere? (Translation: can I use any of this at my day job?)

Relay will be same as React. Including React-Native of course – almost nothing in Relay is browser specific (except for routing).

(source: I'm an engineer on Relay)

Relay is positioned as being complementary to React, and React itself currently works on IE8+. There is talk of phasing out IE8 compatibility from React (probably later this year), but as of today it works on IE8 perfectly fine for us.

Thanks!

None of this tech requires much promotion since it's clearly the new hotness, but there is a silent majority of developers that would appreciate knowing when they can start paying attention professionally. Hopefully soon all JavaScript projects will include a list of supported platforms alongside their corner GitHub banner.

This is very interesting. I'm currently a little bit of the way through solving some of the problems solved by Relay using an existing open source stack, and I'm curious if anyone has any thoughts on how it would compare. I've only skimmed the Relay video, and I haven't created a full React app yet, so forgive me if I get something wrong.

First, for the framework-level handling of fetching all data before rendering, where the data needed by each component is defined in each component, just copy how it's done in react-router's async-data example [1], modified to expect a hash of promises as in [2].

The promises return Backbone-Relational models [3]. You can model arbitrary relations using Backbone-Relational, although many-to-many is apparently kind of hacky (but just needs work to be seamless). It supports parsing REST API responses with nested models and collections as related models. A REST API generator like Flask-Restless [4] creates these responses with a single efficient query.

You have the flexibility to either sync all models before rendering, or render any component without all data already being fetched, and have it automatically re-render when loaded.

Components subscribe and unsubscribe to model events at the proper points in the component lifecycle using react-backbone-component.[5] I missed this and wrote my own version [6] before I found it, but mine is cleaner, slightly more featureful, and presents a simpler API.

Anyway, this requires some work to pull together, but I think it presents a viable alternative that:

- uses existing libraries that do one thing well and allows as much departure from each elements of the architecture as you want

- works with react-router, which is the shit

- works with your existing REST API

Relay looks wonderful, but it's possible to build the abstractions that do pretty much the same thing that support existing REST APIs.

[1] https://github.com/rackt/react-router/blob/master/examples/a...

[2] https://github.com/rackt/react-router/wiki/Announcements

[3] http://backbonerelational.org/

[4] https://flask-restless.readthedocs.org/en/latest/

[5] https://github.com/magalhas/backbone-react-component

[6] https://gist.github.com/mwhite/f763c189f58de7af5d34