I want to separate my schemas and resolvers to separated files as it's kinda big right now in one single file.
I found a library called merge-graphql-schemas but I think that it's redundant with Apollo Server 2 and graphql-tools, the thing is that Apollo Server 2 does already what graphql-yoga does and I don't need to call makeExecutableSchema in the version 1 as I needed before as it's now wrapped inside the new ApolloServer (see here so now I'm wondering, how can I use graphql-tools and mergeSchema with Apollo Server 2?
I don't even know if this approach, I guess called schema stitching is only for remote schemas or it's suited for local ones as well, like having an schema for user, another one for posts, and so on...
How can I accomplish this?
I personally use an approach that isn't doing any stitching, but just using built in language features.
For types defined in strings, you can export from different files. Then import them together and pass them as an array.
import common from './types/common'
import User from './types/User'
import Place from './types/Place'
const typeDefs = [
common,
User,
Place,
]
For resolvers you can do similar,
import userResolver from './resolvers/user'
import placeResolver from './resolvers/place'
// object
import complexGroupOfResolvers from './resolvers/complex'
const resolvers = {
Query: {
getUser: userResolver,
getPlace: placeResolver,
...complexGroupOfResolvers,
}
}
The results of both would be passed to makeExecutableSchema, or directly to a new ApolloServer constructor.
const schema = makeExecutableSchema({
typeDefs,
resolvers,
})
@hasusozam You would then take the schema object from sbrichardson's example and pass it to new ApolloServer({ schema }). The documentation for the ApolloServer constructor says that typeDefs and resolvers are required, but appears to omit that they are not required if schema is supplied.
I use graphql-import to merge schemas and graphql-merge-resolvers to merge my resolvers. Hope can help you.
Closing this because we have experimental modules support that should support this use case.
@martijnwalraven where are these experimental modules?
Most helpful comment
@martijnwalraven where are these experimental modules?