Relay FAQ: Facebook's Data-fetching Framework for React

https://gist.github.com/wincent/598fa75e22bdfa44cf47?

by btown • 11 years ago

239 49 11 years ago

gist.github.com

ndreckshage3• 11 years ago

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

modarts2• 11 years ago

What's "JSON payload control" exactly?

ndreckshage3• 11 years ago

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.

ndreckshage3• 11 years ago

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

j_s2• 11 years ago

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

e1g• 11 years ago

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.

j_s2• 11 years ago

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.

cpojer3• 11 years ago

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)

wincent4• 11 years ago

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

Touche2• 11 years ago

Code example?

cpojer3• 11 years ago

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 ;)

iamartnez3• 11 years ago

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?

Xuzz• 11 years ago

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

snissn• 11 years ago

What language is that?

tel• 11 years ago

Is there a connection between Relay and Haxl?

cpojer3• 11 years ago

no.

wb14123• 11 years ago

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

wincent4• 11 years ago

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.

riobard• 11 years ago

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.

wincent4• 11 years ago

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.

btown• 11 years ago

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.

zkhalique2• 11 years ago

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.

datashaman• 11 years ago

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.

mwhite• 11 years ago

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.

UberMouse• 11 years ago

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.

javamonn• 11 years ago

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

pwpwp• 11 years ago

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

chacham15• 11 years ago

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.

dustingetz• 11 years ago

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?

wincent4• 11 years ago

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.

skrebbel• 11 years ago

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

dlau1• 11 years ago

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.

fattenap• 11 years ago

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

xanderjanz• 11 years ago

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

juliennakache• 11 years ago

Wow! That was fast!

city41• 11 years ago

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.

phi16180• 11 years ago

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

_wo6a• 11 years ago

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

dragonshed• 11 years ago

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.

Relay FAQ: Facebook's Data-fetching Framework for React

Related Stories