Add schema/resolver composition

[helfer]

Right now it's a bit tedious to define a schema in more than one file. Types in the schema and their resolve functions also aren't exactly co-located, which makes code harder to maintain than it is.

Looking for ideas and proposals here to make composition of types easier!

[stubailo]

We could create a simple function, something like bindSchemaAndResolvers, which would just create an object that can be the unit of composability:

const UserSchema = bindSchemaAndResolvers(`
  type User { ... }
`, {
  User: { }
});

Then you could just combine stuff by passing around arrays?

makeExecutableSchema([ UserSchema, WidgetSchema, ...]);

This becomes similar to https://github.com/apollostack/graphql-syntax#graphql-helpers which does almost the same thing but with a "registry" pattern, more similar to Meteor methods/publications which implicitly register themselves.

[stubailo]

http://dev.apollodata.com/tools/graphql-tools/generate-schema.html#modularizing

[migueloller]

@helfer and @stubailo,

What are your thoughts on what I started working on here: https://github.com/bloveit/graphql-utilities?

[stubailo]

I think that's pretty cool! We weren't focusing on incremental adoption with graphql-tools at all, only on making it easy to build a new graphql server from scratch.

If there are modifications that can be made to graphql-tools to meet your needs I'd be happy to accept some PRs!

[migueloller]

@stubailo,

To be honest, I think the natural approach to colocate resolves with the schema definitions would be to build GraphQL types themselves. It allows for easier integration with other tools as well as incremental adoption for somebody looking to build a server using Apollo (think that it would be easier to slowly replace the types using the schema language as opposed to having to rewrite the entire thing using graphql-tools).

To modify graphql-tools to solve these problems then the entire API would need to be changed. I really have no interest in having yet another competing library, and given that the entire Apollo stack is getting some attention I wouldn't mind taking all of the work we're doing with graphql-utilities to graphql-tools if it's something you guys would be alright with.

EDIT: Something that is currently missing from graphql-utilities is proper documentation as to what the extent of the library is, but I'm guessing that you could tell that easily with the initial example. Basically, it's about building normal GraphQL.js types using the schema language.

[stubailo]

Yeah I think it's really important that there are different ways to build graphql schemas and servers - graphql-tools is just one way.

All of the other Apollo tooling like Apollo Client and GraphQL server and GraphQL subscriptions work even if you aren't using this package.

Anyway about your question, I don't think it would make sense to add the entire contents inside here if they aren't going to be integrated with the rest of the approach.

So how does one write resolvers with your package?

[lucasconstantino]

Related: graphql-modules