It sounds like your child components should be fetching their own data via their own graphql queries rather than consuming it as props from the parent that's rendering them.

That way the parent can just render whatever components it wants without having to worry about what data they require.

    <Artist mbid="abc-123">
      <Artist.Name />
      <Artist.Disambiguation />
      <SomeOtherComponentThatHasArtistFieldDescendants />
    </Artist>

    <Artist mbid="abc-123">
      <Artist.Name mbid="abc-123" />
      <Artist.Disambiguation mbid="abc-123" />
      <SomeOtherComponentThatHasArtistFieldDescendants mbid="abc-123" />
    </Artist>

This is a classic static/dynamic problem. Luckily, in the case of React, there may be a really good solution that covers most necessary use cases. First, an analogy:

Consider Ruby's method_missing and corresponding respond_to? methods [1]. method_missing may respond to a method dynamically, but respond_to? should return true if a method will be responded to. If you constrain yourself to normal methods, or carefully defined method_missing bodies, you can predict with 100% accuracy, but what if you do something like this?

    class Whoops
      def method_missing(method)
        if method == :fancy and Random.rand > 0.5
          "it's your lucky day!"
        else
          super(method)
        end
      end

      def respond_to?(method, include_private = false)
        if method == :fancy
          true # Well, actually, "maybe?".
        else
          super
        end
      end
    end

Temporarily ignoring the problem created by randomness: Implementing respond_to? methods is annoyingly redundant. In order to fully-automate the process of implementing respond_to?, you'd need to analyze a method_missing implementation. In the common case, this is static type inference. In the limit case, this is arbitrary abstract interpretation.

However, effectful code, such as this random example, is provably impossible to analyze correctly! You need to have some conservative approximation. Returning true from respond_to? for the :fancy method means that respond_to? should actually be called might_respond_to?.

OK, now back to React and GraphQL: Luckily, over-fetching data is usually not that big a deal (as long as you're within bandwidth constraints). It's often desirable to! Since you might need that data soon when the view changes. Knowning this, it's safe to assume a method for assembling a GraphQL query from fragments can be conservative. That's essentially what a totally static, manual composition of query fragments does. If that's a tight enough approximation for you (like some other commenters have implied) then great! But what if it's not?

Luckily, virtual DOMs are dramatically simpler and less powerful than arbitrary method_missing implementations. If your render method is already pure, you can call it an extra time to use it as its own abstract interpretation. It will produce a virtual DOM, which you can then analyze yourself. For example:

    let capture = (f) => {
      let oldCreateElement = React.createElement;
      try {
        React.createElement = (component, props, ...children) => {
          return {component, ...props, children};
        };
        return f();
      } finally {
        React.createElement = oldCreateElement;
      }
    };

    class DynamicQuery extends React.Component {
      graphql() {
        let dom = capture(() => this.render());
        return gatherQuery(dom);
      }
      render() {
        ...
      }
    }

Here, the gatherQuery method will walk the objects returned by our monkey-patched createElement method, composing query fragments along the way. By following the component references, you can find static methods (easy!), or even instantiate components to do recursive renders yourself (this gets hairy, since React doesn't really make any of this public API). You can do something pretty simple with this: Just hard code a few component types to make some limited dynamic decisions, fallback to static over-query beyond that. Or you can get really fancy and do recursive rendering and analysis, if you really want to.

[1] http://blog.enriquez.me/2010/2/21/dont-forget-about-respond-...

GraphQL is something that's relatively simple (and brilliant) but is one of those things that you just need to try properly first for it to click, especially if you have a background of implementing tons of REST based services.

The GraphQL related tools are top notch and implementing GraphQL server isn't any harder than a REST based server would be (one could even argue that it would be simpler). Even if you don't want to implement everything from scratch, tools like Postgraph[0] exists that pretty much automate it for you.

I made a simple tutorial[1] on wrapping an existing API with GraphQL here which goes through basics of settings up too.

[0] https://github.com/postgraphql/postgraphql [1] https://github.com/motleyagency/devday-tutorials/blob/master...

> it seems that implementing a GraphQL server is not an easy task

It's actually really easy, I encourage you to look into it! I've written plenty of APIs over the years and it's one of the more pleasant experiences I've had.

I wrote this simple 35-line GraphQL server implementing a demo schema in 2 minutes just while I was replying to your comment: https://gist.github.com/exogen/d5ddf86dd7f9efd15d3fabdace759...

You can wrap any existing API with graphql https://medium.com/taller-team/graphql-today-using-apollo-fo...

Regarding implementing GraphQL Servers: You can also check out https://github.com/graphcool/framework (I'm one of the creators) as well as the community driven https://www.howtographql.com/

Facebook’s Relay solves the throughput problem by effectively precompiling queries. Their production apps only make a subset of the requests of the full graphql language - and those are frozen at deploy/compile time. In some sense this makes their production graphql more like “auto-generated REST” from the server’s perspective.

That said, thinking of this in terms of client vs server devs isn’t useful - it’s not like anyone on the team want to see the servers burn. The beauty of graphql is it’s descriptiveness - you could create a query performance score and fail CI if your main page queries are hitting too high of a cost. A meet up in SF last year had some FB engineers discussing this - they do something along these lines before shipping their android/iOS apps.

It's really not that hard to build a relatively optimal GraphQL server. Obviously it requires paying careful attention to performance, and to take steps to mitigate abuse (query whitelists, complexity caps etc). If you were to move the implementation off the server and into the client you'd use a lot of the benefits of GraphQL in the first place (performance being a major one).

It's less about component-level refetching (though you can), it's more about the strong data specificity and composition that is the point of this article. That said, it's up to your query builder to figure out intelligent refreshing / refetching. I use Relay, and it's pretty good at this.

Apollo supports batching queries at the transport layer. graphql-ruby and I'm sure other graphql servers support this out of the box, which means with about ~10 LOC changed you can have your cake (separate queries for independent update) and eat it (combined into one initial call).

The schema should still be documented somewhere, like any API. But even if it's not: GraphQL supports a special "introspection query" that will tell you the entire schema that you can query. Pointing a tool like GraphiQL (https://github.com/graphql/graphiql) at a GraphQL endpoint will even run the introspection query automatically and turn the result into rendered explorable documentation. That's how you figure out what to query.

Usually GraphQL APIs are served alongside a GraphiQL client, which lets you run queries, and read the schema and docs for that API. See, for example, the Star Wars API example: http://graphql.org/swapi-graphql/

I was curious if anyone was going to mention this. We had been looking at GraphQL for our latest project, but realized datomic + pull patterns + re-frame was a more integrated fit.

I hate jacking threads pointing out X instead of Y, but in this case it feels warranted.

Machine learning is not pixie dust.