-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Example of having resolvers in separate files #52
Comments
I would also like to know this as well. We want to define our schemas in one package that also our consumers use. Then define the resolvers in our private server code. If that's at all possible. |
I don't know if I am not missing something, but you certainly can have a const myUberPrivateSchema = {
a() {...}
}
// somewhere else
@SchemaRoot()
export class Schema {
@Mutation()
public a() {
return myUberPrivateSchema.a()
}
} |
Exactly for reason you've described, single schema can have multiple schema roots. Example: import { SchemaRoot, Query, Mutation, compileSchema } from "typegql";
@SchemaRoot()
export class UserSchemaRoot {
@Query()
allUsers() {}
}
@SchemaRoot()
export class UserMutationsSchemaRoot {
@Mutation()
registerUser() {}
}
@SchemaRoot()
export class ProductSchemaRoot {
@Query()
allProducts() {}
}
const finalSchema = compileSchema([UserSchemaRoot, UserMutationsSchemaRoot, ProductSchemaRoot]) As seen, final schema is composed from many 'root' classes. Obviously, those classes can be defined in different files and imported. Technically, you're not importing resolver itself, but you're able to divide your schema logic into many parts and it'd scale horizontally even for huge schema allowing you to have many small, easy to understand files. Let me know if that solves your problem. |
Works for my purposes. Thanks |
In my experience, resolvers can get pretty large. Because of this, I am afraid defining all resolvers in the schema class will become unwieldy. What is the best approach to moving a resolver to a separate file, then using it in the schema class?
If there is an agreement on such a process, I would be happy to amend the documentation.
Currently I have found one approach that seems promising:
The text was updated successfully, but these errors were encountered: