Modular types and incremental imports

[mdebbar]

Follow up on: https://twitter.com/mdebbar/status/869249679862546432
I'll try to illustrate the example from Twitter with more details.

Let's say we have a simple schema for only posts and comments. The QueryType has one field getPost. And the PostType has a field comments.

When using graphql-js, the top-level schema file doesn't have to import everything. It only imports the types necessary for the top-level query fields, and everything else will be included through incremental imports:

// schema.js
import { GraphQLSchema, GraphQLObjectType } from 'graphql';
import PostType from './PostType.js';

const QueryType = new GraphQLObjectType({
  name: 'Query',
  fields: {
    getPost: {
      type: PostType,
      args: { id: ... },
      resolve: (root, { id }) => getPostFromDB(id),
    },
  },
});

export default new GraphQLSchema({
  query: QueryType,
});

// PostType.js
import { GraphQLObjectType, GraphQLList, GraphQLInt } from 'graphql';
import CommentType from './CommentType'

export default new GraphQLObjectType({
  name: 'Post',
  fields: {
    id: { type: GraphQLInt },
    comments: {
      type: new GraphQLList(CommentType),
      resolve: (post) => post.getCommentsFromDB(),
    },
  },
});

I like the approach of graphql-tools which looks cleaner and less verbose, but I couldn't find a way to achieve a structure similar to the above.

cc @stubailo

[stubailo]

Hmm, right now you would have to do:

// PostType.js
import Comment from './CommentType';
import { merge } from 'lodash';

export default {
  typeDefs: [`
    type Post {
      id: Int
      comments: [Comment]
    }
  `, ...Comment.typeDefs],

  resolvers: merge({
    Post: {
      comments: (post) => post.getCommentsFromDB()
    }
  }, Comment.resolvers)
};

import { makeExecutableSchema } from 'graphql-tools';
import { merge, uniq } from 'lodash';
import PostType from './PostType.js';

const typeDefs = [`
  type Query {
    getPost(id: Int!): Post
  }
`, ...PostType.typeDefs];

const resolvers = merge({
  Query: {
    getPost: (root, { id }) => getPostFromDB(id),
  }
}, PostType.resolvers);

export default makeExecutableSchema({
  typeDefs: uniq(typeDefs),  // Need the uniq to avoid having the same string twice
  resolvers
});

I can see where you're coming from that it could be easier. I think something which makes it more natural to pass around a schema/resolver pair and merge them together would be a good fit inside this package, and would probably be just a few lines of code!

Would love to talk about a design for that.

[stubailo]

One point here is that I think I just have a bit of a different mental model - in my mind I feel like all of the types to be kind of part of a whole that are all merged together, rather than small modules with interdependencies.

But we should support both ways of doing stuff, it's just a matter of having a nice unit to pass around/import.

[mdebbar]

Right. I agree with your point about the different mental models.

I think of types as an interconnected graph. And to define a schema, all we need to do is point to the Query node of that graph, and let everything else be figured out automatically:

                            Like *-------------|
                             *                 |
                             |                 |
                             *                 |
Schema * ---- * Query *---* Post *---* Comment |
                  *          *           *     |
                  |          |           |     |
                  |          *           |     |
                  |-------* User *-------|     |
                              *                |
                              |----------------|

So yeah, each type in my mind is a standalone node in the graph.

[stubailo]

Sweet diagram! But yes I'm definitely into having a nicer API for that model.

[mdebbar]

@stubailo I'm trying to come up with a pattern for exporting types as a unit. One thing that I couldn't figure out is how to do the equivalent ofisTypeOf for unions and interfaces.

[stubailo]

Any progress on this? Seems like still a great idea!

[stubailo]

I think we should address this as part of a way to make things more modular/incremental, and I'm planning to use #185 as the main issue for that topic. Closing this but that doesn't mean it's not important!