Resolvers Composition about graphql-tools

[helfer]

Yeah, I like the direction that's going in, but I'm hoping we can make things even more composable than that.

One thing I want to try out (but haven't gotten around to) is see whether we could make type definitions (including reducers) composable. Something like:

import LocationType from './LocationType';

const PersonType = gql`
  type PersonType {
    id: ID!
    name: String
    location: ${LocationType}
    friends: [PersonType]
  }`;

PersonType.resolvers = {
  __self: (parent, args, ctx, info) => ctx.connectors.Person.get(parent[info.fieldName]),
  friends: (person, args, ctx) => ctx.connectors.Friends.get(person.id)
}

export default PersonType;

In the example above, each type has its own resolvers attached to it. Because we use tagged template strings, we could extract those and store the type definitions and resolve functions properly until a schema is created. Does that make sense? I think it has the advantage of being really clear because the resolvers are co-located with the type definitions and move around with them.

Another thing to note about the example above is the idea of a default resolve function for a type. If a type is used in a context where no resolve function is defined for it (as LocationType is above), then its default resolve function will be used, as defined in __self. In this case, it will fetch a person with the id defined in parent. So if parent is { id: 55, bestFriend: 12 } and bestFriend is of type Person, then the default Person resolver will fetch the person with id 12 for that friend. No need to define the resolve function. I like the reusability of that, but I'm not sure if it will make the code more opaque, because suddenly you're no longer sure which resolver will be applied (the type default resolver, or the GraphQL default resolver (which just returns parent[info.fieldName]).

[muhammad-abubakkar]

How to write resolver for union type. e.g
union Vehicle = Car | Cycle | Bus
type Result {
no :Int!
vehicle: Vehicle
}
How to write resolver for Vehicle union so that i can query Result

[abhiaiyer91]

Thoughts for creating resolvers

// super basic func
export default function combineResolvers(namespace, resolvers) {
  // iterate and check for dupes
  // chec they are functions etc
  return {
    [namespace]: resolvers
  };
}

import  {
    usecontext,
    useTestConnector
} from './testResolvers';

import { testMutation } from './testMutations';

import cartResolver from './cartResolver'; 

const rootQuery = combineResolvers("RootQuery", {context: usecontext, testConnectorName: useTestConnector});
const rootMutation = combineResolvers("RootMutation", { testMutation });
const Product = combineResolvers("Product", { cart: cartResolver})
export default Object.assign({}, ...rootQuery, ...rootMutation, ...Product);

[abhiaiyer91]

I like that! I do question default resolvers because you're right, it makes the code more opaque. And also I think it causes unneeded friction. A user should define their resolvers for each type, I'm not sure the gain is for writing a default resolved if you're already going to be resolving the type. I'd like to continue playing around with what you mentioned above. Thanks!

[helfer]

A user should define their resolvers for each type

You mean for each field? Because the default resolver I proposed would be per type. Right now GraphQL-JS doesn't have that.

[abhiaiyer91]

Sorry I mixed up the terminology. Field.

[helfer]

The thing with type resolvers (aka default resolvers) is that they'd be a very convenient way of repeating yourself less often. They're also useful if we want to have a type decorator which defines where a certain type is fetched (REST, pg, mongoDB etc.). Otherwise we have to specify that per field (which might be okay).

I probably won't implement it now, but it's something to keep in mind for later.

[helfer]

closing this ancient discussion issue.

[worldsayshi]

What's the development on this? Is there any sanctioned way to compose schemas and resolvers? I can't find any relevant material.

[jmatsushita]

I also ended up here trying to understand how for instance you could have several Query declarations in sub-schemas with the example in the docs

[stubailo]

I think you can just create two query documents and merge them. Want to try and add a PR to the docs?

[worldsayshi]

My issue was mainly to merge an executable (parsed) schema with one created programmatically, specifically one coming from elasticsearch-graphql.

This way I could have my elasticsearch side-by-side with my front end api while developing.

[lucasconstantino]

I've done some work on modularizing the schema here: graphql-modules.
Something that may be of interest is another recent (today! yay!) project of mine: graphql-resolvers

Hope it helps someone. And you guys are very welcome to add issues and suggestions over there, if it suits ;)