Trying to use gqlgen to remove some of the map[string]interface{} madness for golang development.
But some “features” of dgraph are complicating my efforts. For instance, dgraph automagically fills in interface fields for “concrete” types in SDL. From the docs: “When a type implements an interface, GraphQL requires that the type repeats all the fields from the interface, but that’s just boilerplate and a maintenance problem, so Dgraph doesn’t need that repetition in the input schema and will generate the correct GraphQL for you.”
But gqlgen (rightly) balks at the fact that the concrete type does not contain the field:
failed to load schema: internal/data/schema.graphql:54: For Vendor to implement Organization it must have a field called name.
OK, so I figure I’d give up the nicety that dgraph’s providing and make the schema compliant by adding in the boilerplate (duplicate the fields in the concrete type).
But that approach causes dgraph to fail when trying to update the schema:
{"errors":[{"message":"couldn't rewrite mutation updateGQLSchema because input:1: Field Organization.anme can only be defined once.\n","extensions":{"code":"Error"}}]}
Hi Matthew
We don’t currently have a repo with gqlgen but you can take a look at this repo instead in which we have generated types for our schema as well - Apollo Server with Dgraph . And here is the schema for the server and then here you can find mutations example where we delegate it to Dgraph. Not sure which function in gqlgen does the same but should be possible, if this isn’t clear I can come up with an example using that, if you want.
So you should submit the original schema to Dgraph like you did before and you don’t need to send the schema that is in the Go server.
I hope this helps, let me know if you have any more questions.
Thanks Apoorv… I was hoping to find an example of code using gqlgen to generate Go structs from dgraph-compliant SDL (again to automate much of the map[string]interface{} madness that’s needed when communicating from Go to the graphql endpoint). I’ll keep looking…
Indeed. For instance, have a look at this example boilerplate that @bkennedy wrote for his demonstrative golang+graphql+dgraph repo: https://github.com/dgraph-io/travel/blob/master/internal/data/mutate_city.go. This is just one of many query and mutation modules he wrote to deal with graphql via golang. There’s lots of duplication in there.
I feel there’s an opportunity with some of the core from either (maybe both) gqlgen or graphql-go to easily create complex Go structs via go generate for representation, querying and mutating. Looking at my MVP I can see tons of custom query/mutations on my horizon. And with more than two dozen types in my current schema, a tool like this would eliminate migration fragility.
It might be a little more involved that just a basic example, but I’d appreciate any guidance.
I don’t believe in code generation for many reasons. In this case, I rather hand code the Go types and write the code to make the calls. If/when there are bugs, I must have control over the code. I have strong design philosophies and experience on this.
But I think there are people who would be interested in such a tool.