Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: