-
Notifications
You must be signed in to change notification settings - Fork 492
define schema programmatically #14
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
Comments
Yes, this sounds very similar to #1. As already mentioned there, I would prefer to combine multiple textual schema definitions. Programmatically defined GraphQL types would conflict with the "minimal API" goal stated in the Readme.
One property of graphql-go is that there is no 1-to-1 relationship between GraphQL types and Go types. The Go type of the resolver is completely determined by how you got that resolver (e.g. the return type of the parent resolver's method). Thus I think what you're suggesting does not fit into this architecture. Modularization is also important to me, I'm sure we'll find ways to make it possible in a simple and non-magic way. |
Imho a schema should not be generated. The schema is the ground truth, the simplest way to express how your API looks like. The implementations are then matched against the schema. |
I agree, since the graphql schema is very minimal and clean, it is not too hard to maintain it. I would start trying in my project and see how it works. Also, curious about the relay example as my project is similarly structured and would be a great example to follow. thank you for all the hard work. cheers. |
Hi,
akin to how custom scalars can be defined, is it possible to define graphql types programmatically. One use case is to generate schema definition through code generation, say with the resolver struct and some struct tags. This may be related to #1 , but it may also help with modularization if a resolver also can set along with type registration. What do you think?
Thanks,
bsr.
The text was updated successfully, but these errors were encountered: